Gmail MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between list_emails and search_emails, as both retrieve emails with similar outputs, which could cause confusion. Additionally, authenticate and login_tool both handle authentication initiation, though their descriptions clarify different aspects of the process. Overall, the set is mostly clear with minor ambiguities.
Naming Consistency4/5
The naming follows a consistent snake_case pattern throughout, with clear verb_noun structures (e.g., get_email, list_emails, create_calendar_event). However, there are minor deviations like authenticate and login_tool, which are less descriptive compared to others, and check_auth_status uses a verb_adjective_noun pattern, slightly breaking consistency.
Tool Count4/5
With 17 tools, the count is slightly high but reasonable for a Gmail and Calendar integration, covering authentication, email management, and calendar operations. It avoids being excessive, though some tools like authenticate and login_tool could potentially be consolidated to streamline the set.
Completeness5/5
The tool set provides comprehensive coverage for Gmail and Calendar operations, including authentication, email listing/searching/replying, calendar event creation/listing, and integration features like detecting events from emails. There are no obvious gaps; it supports full workflows from access to action, including user confirmation steps for sensitive operations.
Average 4.2/5 across 17 of 17 tools scored. Lowest: 3.2/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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions processing OAuth2 codes and states but lacks critical details: it doesn't specify if this completes authentication, stores tokens, requires specific permissions, or handles errors beyond returning a message. For a security-sensitive OAuth tool with zero annotation coverage, this is a significant gap in transparency.
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 well-structured and front-loaded with the core purpose, followed by clear Arg/Return sections. Every sentence adds value: the first defines the tool's role, and the subsequent lines document parameters and output without redundancy. It's appropriately sized for a simple tool with two parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (OAuth processing, 2 parameters, no annotations, no output schema), the description is minimally adequate. It covers the basic purpose and parameters but lacks details on behavioral outcomes, error handling, and integration with sibling tools. Without annotations or output schema, it should do more to guide safe and correct usage in an authentication context.
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 0%, so the description must compensate. It adds meaningful context by explaining that 'code' and 'state' come from Google OAuth, which clarifies their origin and purpose beyond the bare schema. However, it doesn't detail format constraints (e.g., code length, state matching), leaving some ambiguity. With 2 parameters and no schema descriptions, this is above baseline but not fully comprehensive.
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 ('Process') and the resources ('OAuth2 authorization code and state'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from sibling authentication tools like 'authenticate' or 'login_tool', which likely handle related OAuth flows, leaving some ambiguity about when to choose this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., after receiving a callback from Google OAuth), exclusions, or how it relates to sibling tools like 'authenticate' or 'check_auth_status', leaving the agent to infer usage context 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.
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 states the tool 'provides a direct way to check' and mentions the return type ('Dict[str, Any]: The authentication status'), which adds some behavioral context. However, it lacks details on error handling, performance, or what specific authentication aspects are checked, leaving gaps in transparency.
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 appropriately sized with three sentences: purpose statement, context about being a 'direct way', and return value. It's front-loaded with the main purpose and avoids unnecessary details. However, the return value explanation could be slightly more concise, as 'Dict[str, Any]' might be inferred from context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is somewhat complete but has minor gaps. It explains the purpose and return value, but without annotations or output schema, it could benefit from more detail on what 'authentication status' includes (e.g., user info, expiry) to fully guide an agent.
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 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately avoids discussing any. This meets the baseline for tools with no parameters.
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's purpose: 'Check the current authentication status' with a specific verb ('check') and resource ('authentication status'). It distinguishes from siblings by mentioning it's a 'direct way' without accessing 'auth://status resource', though it doesn't explicitly differentiate from other auth-related tools like 'login_tool' or 'logout'.
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 by stating it's for checking authentication 'without having to access the auth://status resource', suggesting an alternative method. However, it doesn't provide explicit guidance on when to use this tool versus other auth-related siblings (e.g., 'login_tool', 'logout'), nor does it mention prerequisites or 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?
With no annotations provided, the description carries full burden. It discloses the tool is a read operation ('Get', 'provides'), returns structured data, and includes a behavioral note about email_link usage. However, it lacks details on rate limits, error conditions, authentication requirements, or whether it's cached/real-time. The description doesn't contradict annotations (none exist), but could be more comprehensive for a tool accessing user data.
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 well-structured with clear sections: purpose statement, elaboration, returns documentation, and a usage note. It's moderately concise (5 sentences), though the returns section is detailed. Every sentence adds value: the first states purpose, second elaborates scope, third documents output, fourth details output structure, fifth provides behavioral guidance. Minor verbosity in returns listing keeps it from a perfect 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?
Given no annotations, no output schema, and 0 parameters, the description does a fair job: it clearly explains what the tool does and documents the return structure. However, for a tool accessing sensitive data (emails), it lacks context on authentication needs, data freshness, or error handling. The output documentation helps, but without an output schema, the description must fully specify returns—which it does adequately but not exhaustively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on output semantics. This meets the baseline for zero-parameter tools, though it doesn't add value beyond the schema (which is fine here).
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's purpose: 'Get a simple overview of the user's emails' and specifies it provides a 'quick summary of the user's Gmail account, including counts and recent emails, all in one call.' This distinguishes it from siblings like get_email (single email) or list_emails (full listing). However, it doesn't explicitly differentiate from get_email_count (which might overlap with counts).
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 ('quick summary', 'all in one call') suggesting it's for high-level overviews rather than detailed queries. It doesn't explicitly state when to use this vs. alternatives like list_emails or get_email_count, nor does it mention prerequisites (e.g., authentication status). The note about including email_link provides some guidance but is more about output usage than tool selection.
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 initiates an OAuth2 flow and returns an authorization URL, which is useful behavioral context. However, it lacks details on error handling, rate limits, or security implications, leaving gaps for a tool handling authentication.
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 front-loaded with the core purpose in the first sentence, followed by a concise 'Returns' section. It uses minimal words effectively, with no redundant information, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of OAuth2 authentication and no annotations or output schema, the description is moderately complete. It explains what the tool does and the return value, but lacks details on integration steps, error cases, or how it fits with sibling tools like 'process_auth_code_tool', leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info beyond the schema, but this is acceptable given the lack of parameters, aligning with the baseline for 0 params.
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's purpose: 'Initiate the OAuth2 flow by providing a link to the Google authorization page.' It specifies the action (initiate OAuth2 flow) and resource (Google authorization page), though it doesn't explicitly distinguish it from sibling tools like 'process_auth_code_tool' or 'check_auth_status'.
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 by mentioning OAuth2 flow initiation, suggesting it's for authentication setup. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'process_auth_code_tool' or 'authenticate', nor does it specify prerequisites or 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the tool's actions (revoking token, clearing credentials) and return type (success/error message), which covers basic behavior. However, it lacks details on potential side effects (e.g., impact on other tools), error conditions, or rate limits, making it adequate but not comprehensive.
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 front-loaded with the core action in the first sentence and includes a concise 'Returns' section. Every sentence adds value without redundancy, making it efficiently structured and appropriately sized for a simple tool.
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 (0 parameters, no output schema, no annotations), the description is mostly complete: it explains what the tool does and what it returns. However, without annotations or output schema, it could benefit from more detail on behavioral aspects like error handling, but it suffices for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter-specific information, which is appropriate. A baseline of 4 is assigned as it effectively handles the lack of parameters without introducing confusion.
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 explicitly states the tool's purpose with specific verbs ('log out', 'revoking', 'clearing') and resources ('access token', 'stored credentials'), clearly distinguishing it from sibling tools like login_tool or check_auth_status. It goes beyond a tautology by detailing the actions involved in logging out.
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 usage in the context of ending a session or authentication state, which is clear from the action described. However, it does not explicitly state when to use this tool versus alternatives (e.g., no guidance on prerequisites like being logged in first) or any exclusions, leaving some room for ambiguity.
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 effectively describes key traits: authentication prerequisites, pagination behavior (via 'next_page_token'), and output structure (list of events with details and links). It also includes important usage notes about including 'event_link' for user access. It does not mention rate limits or error handling, but covers essential operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (Prerequisites, Args, Returns, Example usage, Important), but it is verbose with repetitive elements (e.g., restating tool name in examples) and overly detailed usage notes that could be condensed. Every sentence adds value, but efficiency could be improved by trimming 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 tool with no annotations, no output schema, and 4 parameters, the description is largely complete: it covers purpose, prerequisites, parameters, returns, examples, and important behavioral notes. It lacks explicit error handling or rate limit info, but given the context signals, it provides sufficient guidance for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage, the description fully compensates by detailing all four parameters: 'max_results' (defaults, purpose), 'time_min' and 'time_max' (formats, defaults, purpose), and 'query' (purpose). It adds meaning beyond the schema by explaining usage contexts, formats (ISO or natural language), and defaults, making parameters clear and actionable.
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 purpose: 'List events from the user's Google Calendar' and 'retrieves a list of upcoming events from the user's calendar.' It uses specific verbs ('list,' 'retrieves') and identifies the resource ('Google Calendar events'), distinguishing it from siblings like 'create_calendar_event' or 'detect_events_from_email.'
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 provides clear context for usage through prerequisites (authentication required) and example scenarios (listing upcoming events, specific time ranges, searching). However, it lacks explicit guidance on when not to use this tool or direct alternatives among siblings, such as 'search_emails' for email-related events.
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 effectively describes key behaviors: it opens a browser window, starts a local server, handles callbacks, and returns a message. This covers the interactive and server aspects well, though it could mention potential user interaction requirements or error handling.
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 front-loaded with the main purpose, followed by implementation details and return value in three clear sentences. Each sentence adds value: the first states the action, the second explains the mechanism, and the third specifies the output. There is no wasted text.
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 complexity (OAuth flow with browser/server interaction), no annotations, and no output schema, the description is mostly complete. It explains what the tool does, how it works, and the return type. However, it could improve by detailing prerequisites (e.g., requires user interaction) or error cases, slightly reducing 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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on the tool's action and return value without redundant parameter details, earning a baseline score of 4 for this context.
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 purpose with specific verbs ('Start', 'opens', 'starts') and resources ('OAuth authentication process', 'browser window', 'local server', 'callback'). It distinguishes itself from sibling tools like 'login_tool' or 'process_auth_code_tool' by describing the complete OAuth flow initiation rather than just checking status or processing codes.
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 usage context by stating it 'starts the complete OAuth authentication process,' suggesting this should be used when initial authentication is needed. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, such as 'check_auth_status' for verification or 'process_auth_code_tool' for handling codes.
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 effectively describes key behavioral traits: it's a write operation (creates new events), requires authentication, specifies that the current user is automatically added to attendees, and indicates the tool will return missing information to ask the user. It doesn't mention rate limits or error handling, but covers the essential mutation behavior well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Prerequisites, Args, Returns, Example usage), but it's quite lengthy with detailed parameter explanations and multiple examples. Some information could be more concise, though all content appears purposeful. The front-loading is good with the core purpose stated first.
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 complexity of a 7-parameter write operation with no annotations and no output schema, the description provides excellent completeness. It covers authentication requirements, parameter semantics, return value structure, and includes practical examples. For a mutation tool with rich parameters, this description gives the agent everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must fully compensate. It provides comprehensive parameter semantics beyond just names: it explains what each parameter represents, gives format examples (ISO format or natural language for start_time), specifies optional parameters and their default behaviors, and provides usage examples. This adds significant value beyond the bare 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 action ('Create a new event') and resource ('in the user's Google Calendar'), distinguishing it from sibling tools like 'list_calendar_events' or 'suggest_meeting_times'. The verb 'create' is unambiguous and the resource scope is well-defined.
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 provides clear context about when to use this tool (for creating calendar events) and includes prerequisites (authentication with Google Calendar access). However, it doesn't explicitly state when NOT to use it or name specific alternatives among sibling tools, though the context implies it's for creation versus listing or suggesting.
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 effectively describes authentication requirements, return format (dictionary with specific fields), and pagination behavior ('next_page_token'). However, it doesn't mention rate limits, error conditions, or whether the operation is read-only (though implied by 'get').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, prerequisites, returns, example) but contains some redundancy. The example usage largely repeats information from prerequisites, and the returns section could be more concise. Most sentences earn their place, but there's room for tighter editing.
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 (0 parameters, no output schema, no annotations), the description is quite complete. It covers purpose, prerequisites, return format, and usage examples. The main gap is the lack of explicit mention that this is a read-only operation (though implied), and no information about potential errors or rate limits.
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 with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on prerequisites and return values. No additional parameter information is needed or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('get', 'retrieves') and resources ('count of emails', 'total number of messages', 'number of messages in the inbox'). It distinguishes this tool from siblings like 'list_emails' (which likely returns message details) and 'get_email' (which retrieves specific messages) by focusing exclusively on counts.
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 usage guidance with prerequisites ('user must be authenticated'), specific alternative actions ('check auth://status resource first', 'guide the user through authentication'), and a step-by-step example. It clearly distinguishes when to use this tool versus authentication-related siblings like 'check_auth_status' and 'authenticate'.
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 effectively describes key behavioral traits: authentication requirements, pagination behavior (mentions next_page_token), and what information is returned (basic information about each email). It doesn't mention rate limits, error conditions, or whether this is a read-only operation (though 'list' implies it), preventing a perfect score.
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 well-structured with clear sections (purpose, prerequisites, args, returns, example usage) and every sentence adds value. It could be slightly more concise by combining some of the example usage steps, but overall it's efficiently organized with no wasted text.
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 moderate complexity (2 parameters, no output schema, no annotations), the description provides comprehensive context: purpose, prerequisites, parameter details, return format, and usage examples. The only minor gap is lack of explicit mention that this is a read-only operation (though implied by 'list'), preventing a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema, which has 0% description coverage. It explains both parameters thoroughly: max_results specifies the maximum number of emails with a default value, and label provides the filtering purpose with default value and common examples (INBOX, SENT, etc.). This fully compensates for the schema's lack of descriptions.
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's purpose: 'List emails from the user's mailbox' and 'retrieves a list of emails from the specified label in the user's Gmail account'. It specifies the resource (emails) and verb (list/retrieve) with context about the source (Gmail account). However, it doesn't explicitly differentiate from sibling tools like 'search_emails' or 'get_email', which is why it doesn't reach a score of 5.
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 usage guidelines with prerequisites (authentication required, check auth://status first), step-by-step instructions for when to use it (including alternatives like guiding authentication if not authenticated), and context about when to include email links. It clearly distinguishes this from authentication tools and provides concrete usage scenarios.
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 and does so effectively. It discloses key behavioral traits: the draft is saved but not sent automatically, user confirmation is required, and it returns specific fields (draft_id, confirmation_required). However, it doesn't mention potential errors, rate limits, or authentication details beyond prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately front-loaded with the core purpose, but it includes extensive procedural details (7-step example) and repetitive warnings about user confirmation. While helpful, this makes it longer than necessary; some information could be condensed without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides strong contextual completeness: it explains prerequisites, parameters, return values, and usage flow. However, it lacks explicit error handling information and doesn't fully detail the output structure beyond the listed fields, leaving some gaps for a mutation tool.
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 0%, so the description must compensate. It adds meaningful context for all three parameters: email_id (obtained from list_emails() or search_emails()), reply_text (text of the reply), and include_original (whether to include original email, with default True). This goes beyond the bare schema, though it doesn't detail format constraints for email_id or reply_text.
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 action ('create a draft reply') and resource ('to an email'), distinguishing it from siblings like 'confirm_send_email' (which sends) and 'prepare_email_reply' (which prepares context). It explicitly notes the draft is saved but not sent, which differentiates it from actual sending tools.
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 on when to use this tool, including prerequisites (authentication, obtaining email ID, using prepare_email_reply first) and clear alternatives (e.g., using list_emails() or search_emails() to get email IDs). It also specifies when NOT to use it (never assume automatic sending) and the subsequent step (confirm_send_email).
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 and does well by disclosing behavioral traits: it explains the tool's analysis process (identifying events based on dates/times/clues), prerequisites (authentication, email ID source), and important constraints (always ask for confirmation, never use defaults). It doesn't mention rate limits or error handling, but covers key operational aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately structured with sections (purpose, prerequisites, args, returns, example, important), but it's verbose with 5 example steps and 4 'Important' rules that could be condensed. Some sentences (e.g., the full workflow) are redundant with usage guidelines, reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides good context: it explains the tool's purpose, parameters, returns (including specific fields like success, events, email_link), and integration with sibling tools. However, it lacks details on error cases or output structure beyond the high-level return dict description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It explicitly documents the single parameter email_id, explaining it's 'The ID of the email to analyze for events' and linking it to prerequisites (from list_emails or search_emails). This adds crucial meaning beyond the bare 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 action ('detect potential calendar events') and resource ('from an email'), distinguishing it from siblings like list_calendar_events or create_calendar_event. It explicitly mentions analyzing dates, times, and contextual clues, providing a precise purpose.
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 prerequisites (authentication, email ID from list_emails or search_emails) and clear when-to-use guidance in the Example Usage section, which outlines a workflow and distinguishes this tool from create_calendar_event. It also specifies important usage rules like asking for confirmation and missing information.
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 full burden and does well: it discloses authentication requirements, prerequisites for obtaining email IDs, and the comprehensive nature of the returned context. It doesn't mention rate limits, error conditions, or performance characteristics, but covers essential behavioral aspects for a context-gathering tool.
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?
Well-structured with clear sections (description, prerequisites, args, returns, example usage). The description is appropriately sized for a complex tool, though the example usage section is somewhat verbose. Every sentence adds value, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with no annotations and no output schema, the description provides substantial context: purpose, prerequisites, parameter explanation, detailed return value structure, and usage workflow. The main gap is lack of error handling information, but overall it's quite complete for agent guidance.
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 0%, but the description compensates well: it explains that email_id is 'The ID of the email to reply to' and provides guidance on obtaining it from list_emails() or search_emails(). While it doesn't specify format constraints (like expected string pattern), it adds meaningful context beyond the bare 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 tool's purpose: 'Prepare a context-rich reply to an email' with specific details about what context is gathered (original email, thread history, sender information, etc.). It distinguishes from siblings like 'send_email_reply' (which actually sends) and 'get_email' (which retrieves single emails without comprehensive context).
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?
Explicit guidance is provided: 'Prerequisites' section states authentication requirements and how to obtain email IDs from list_emails() or search_emails(). The 'Example usage' section gives a step-by-step workflow, clearly indicating when to use this tool versus alternatives like list_emails() for ID acquisition and send_email_reply() for actual sending.
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 does an excellent job describing key behavioral traits: it respects existing calendar events, limits suggestions to working hours (default 9am-5pm), excludes weekends by default, returns at most 10 suggestions, and requires authentication. The only minor gap is not mentioning potential rate limits or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, prerequisites, args, returns, examples, important notes) and every sentence adds value. It's slightly longer than ideal but efficiently conveys necessary information. The front-loaded purpose statement is excellent, though some redundancy exists between the initial description and later elaboration.
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 complexity (calendar analysis with multiple parameters) and the absence of both annotations and output schema, the description provides complete context. It covers authentication requirements, behavioral constraints, parameter details, return value structure, and practical examples. This is comprehensive enough for an agent to understand and use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing detailed parameter semantics. It explains each parameter's purpose, format expectations (natural language for dates, '9-17' format for working hours), default values, and optional status. The examples further clarify how to use the parameters in practice.
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 purpose: 'Suggest available meeting times within a date range' and elaborates that it 'analyzes the user's calendar and suggests available time slots for scheduling meetings based on their existing calendar events.' This is a specific verb+resource combination that distinguishes it from sibling tools like 'list_calendar_events' or 'create_calendar_event'.
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 provides clear context about when to use this tool (for finding available meeting times based on calendar analysis) and includes prerequisites (Google Calendar authentication). However, it doesn't explicitly state when NOT to use it or mention specific alternatives among the sibling tools, such as when to use 'list_calendar_events' instead.
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 effectively describes the tool's behavior as a mutation operation (sending an email), includes prerequisites (authentication, draft_id, user confirmation), and emphasizes the critical safety requirement (explicit user confirmation). However, it lacks details on potential side effects (e.g., email delivery status, error handling) or rate limits, which would enhance transparency further.
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 well-structured with sections (Prerequisites, Args, Returns, Example usage, IMPORTANT) and front-loaded key information. Most sentences earn their place by providing critical guidance, though the example usage could be slightly condensed without losing clarity. Overall, it is appropriately sized and organized for the tool's complexity.
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 complexity (a mutation with safety-critical requirements), no annotations, and no output schema, the description is complete. It covers purpose, usage guidelines, behavioral traits (including prerequisites and safety warnings), parameter semantics, and return values, providing all necessary context for an AI agent to use the tool correctly and safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must fully compensate. It clearly explains the single parameter 'draft_id' as 'The ID of the draft to send,' specifying its source ('from send_email_reply()') and purpose. This adds essential meaning beyond the bare schema, making the parameter's role and requirements explicit.
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 action ('send a previously created draft email') and resource ('draft email'), distinguishing it from sibling tools like 'send_email_reply' (which creates drafts) and 'get_email' (which retrieves emails). It explicitly mentions the confirmation requirement, making the purpose distinct and well-defined.
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 on when to use this tool ('after explicit user confirmation to send the email') and when not to use it ('Never call this function without explicit user confirmation'). It also lists prerequisites (authentication, draft_id from send_email_reply, user confirmation) and references the sibling tool 'send_email_reply' for creating drafts, offering clear alternatives and context.
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. It discloses important behavioral traits: authentication requirements ('The user must be authenticated'), data source dependencies (email ID from other tools), and usage guidance ('Always include the email_link when discussing the email with the user'). However, it doesn't mention rate limits, error conditions, or performance characteristics.
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 well-structured with clear sections (purpose, prerequisites, args, returns, example usage) and front-loaded with the core purpose. However, the example usage section is somewhat verbose and could be more concise while maintaining clarity.
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 no annotations and no output schema, the description provides comprehensive context: clear purpose, usage guidelines, parameter semantics, detailed return value documentation, and practical examples. It addresses all necessary aspects for a read operation with one parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It provides rich semantic context for the single parameter: explains what email_id is, where it comes from (list_emails() or search_emails()), and its purpose. This adds significant value beyond the bare 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 action ('retrieves the full details of a specific email') and resource ('email by ID'), distinguishing it from siblings like list_emails (which lists multiple emails) and search_emails (which searches with criteria). The verb 'retrieves' is precise and the scope is well-defined.
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 explicitly states when to use this tool ('Get a specific email by ID') and provides clear prerequisites (authentication, obtaining email ID from list_emails() or search_emails()). It also distinguishes from alternatives by specifying this is for retrieving a single email by ID, not listing or searching multiple emails.
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 effectively describes key traits: authentication requirements, default behavior (max_results defaults to 10), pagination support (via next_page_token), and output structure. However, it lacks details on rate limits, error handling, or specific permissions needed, leaving some gaps in 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for prerequisites, arguments, returns, and example usage, making it easy to scan. However, it includes some redundancy (e.g., repeating the tool's purpose) and could be more front-loaded; the core functionality is clear, but minor trimming could improve efficiency without losing value.
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 complexity (search functionality with authentication needs), no annotations, and no output schema, the description is highly complete. It covers purpose, usage, parameters, return values, and authentication workflow, providing all necessary context for an AI agent to invoke the tool correctly and handle edge cases like authentication states.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% coverage. It explains both parameters in detail: 'query' with examples of Gmail syntax and 'max_results' with its default value and optional nature. This compensates fully for the schema's lack of descriptions, providing clear semantics and usage examples.
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 purpose: 'Search for emails using Gmail's search syntax.' It specifies the verb ('search'), resource ('emails'), and method ('Gmail's search syntax'), distinguishing it from siblings like 'list_emails' or 'get_email' by emphasizing search functionality rather than listing or retrieving specific emails.
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 usage guidelines, including prerequisites (authentication via 'auth://status'), when to use (after authentication), and alternatives (e.g., guiding users to authenticate first). It also references sibling tools like 'authenticate' and 'check_auth_status' in the context of authentication steps, offering clear guidance on tool selection.
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 MCP server](https://glama.ai/mcp/servers/bastienchabal/gmail-mcp/badges/card.svg)](https://glama.ai/mcp/servers/bastienchabal/gmail-mcp)

Score Badge

Copy to your README.md:

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

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/bastienchabal/gmail-mcp'

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