multi-gmail-mcp
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation2/5
Every tool appears twice with and without the 'multi_gmail_' prefix, making it hard for an agent to distinguish which version to call. Additionally, 'fetch_sent' is deprecated but still present, causing overlap with the more general 'fetch' tool.
Naming Consistency2/5The tool naming is inconsistent due to the dual prefixes. While each group individually follows a verb_noun pattern, the coexistence of unprefixed and 'multi_gmail_' prefixed tools violates consistency and suggests redundancy.
Tool Count2/5With 42 tools, the count is inflated because of deliberate duplication. The actual unique tool set is about 21, which would be appropriate for a Gmail MCP, but the duplication makes the tool surface unnecessarily large and confusing.
Completeness4/5The unique tool set covers essential Gmail operations: fetch, read, send, draft, archive, follow-ups, account management, and diagnostics. Minor gaps exist (e.g., no delete or label management), but core workflows are well-supported.
Average 3.6/5 across 42 of 42 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only states it 'verifies' and 'suggests next action', but does not explain what happens on success/failure, whether any modifications occur, or any side effects. Lacks transparency about the nature of the check and output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it sacrifices completeness for brevity. While it front-loads the purpose, it omits parameter details and behavioral context, which are essential for correct usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, two undocumented parameters, and no annotations, the description fails to provide sufficient context. It does not explain the return format, how to interpret results, or the role of parameters, leaving significant gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain the two parameters 'accountAlias' and 'chatScope' at all. An agent has no information on how these affect the diagnostics, making parameter usage unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state the tool performs a health check on specific components (credentials path, accounts storage, reminders store, active account binding) and suggests next action. This is a specific verb-resource combination, but it does not differentiate itself from sibling tools like 'multi_gmail_diagnostics' or 'status'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'status' or 'multi_gmail_diagnostics'. No prerequisites, exclusions, or context for appropriate usage are provided.
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 bears full responsibility for behavioral disclosure. It mentions that the tool 'waits if needed' and that 'no manual code copy required', but it does not disclose if the operation is destructive, read-only, or what happens on failure. It lacks details on authentication flow or prerequisites beyond browser approval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose, but it is too terse. While it wastes no words, it fails to include essential information about parameters and behavior, making it under-specified. Every sentence should earn its place, but the missing param info is a significant omission.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 params with zero schema descriptions, no output schema, no annotations), the description is incomplete. It does not explain parameters, return values, error cases, or prerequisites beyond browser approval. The tool is part of a multi-account flow, but the description does not emphasize this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three parameters (code, pendingAlias, chatScope) with zero description coverage. The description does not mention any of these parameters or their purposes, leaving the agent completely in the dark about what values to provide. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to finish the Gmail login after browser approval. The verb 'Finish' and resource 'Gmail login' are specific. However, it does not explicitly differentiate from the sibling 'connect_finish' tool, though the 'multi' prefix implies multi-account context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit next steps ('After success, run `set_signer`, then `fetch`'), which guides the agent on what to do after using this tool. However, it does not mention when not to use this tool, nor does it explicitly state the prerequisite of having initiated the connection with a 'connect' tool first.
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 full burden. It discloses that the tool refreshes thread state and returns full context, but does not clarify whether state modification occurs or the exact nature of 'refresh'. The guideline about not calling followup_send without approval is helpful but not a behavioral trait of the tool itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long and front-loaded with core functionality. The third sentence about sending is somewhat tangential but still concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, and two undocumented parameters, the description is incomplete. It fails to clarify parameter usage or differentiate from the sibling 'followup_due', though it covers the main purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (accountAlias, chatScope) with no description and 0% schema coverage. The tool description does not explain what these parameters represent or how to use them, leaving the agent without guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists due reminders and refreshes thread state. However, it does not differentiate from the sibling tool 'followup_due', which likely serves a similar purpose without multi-account support.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidelines for the follow-up send action but does not specify when to use this tool over alternatives like 'followup_due' or 'multi_gmail_followup_cleanup'. No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It mentions 'Waits if needed; no manual code copy required,' which hints at automatic waiting and code handling. However, it lacks critical details: error conditions, timeouts, what happens if the code is invalid, and the role of the three parameters (code, pendingAlias, chatScope) are not explained. This leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that define purpose and provide a follow-up sequence. It is front-loaded with the core action. However, it could be slightly more structured by listing parameters or clarifying the waiting behavior, but overall it avoids waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no output schema, no annotations), the description is incomplete. It fails to explain what each parameter does, how to handle errors, or what the return value is (if any). The only contextual hint is the follow-up command, but that does not suffice for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameter meanings. The description does not mention any parameters; it only gives a follow-up command. The three parameters (code, pendingAlias, chatScope) are left completely unexplained, making it impossible for an agent to know what values to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Finish Gmail login after browser approval.' It uses a specific verb ('Finish') and resource ('Gmail login'). However, it does not differentiate from sibling tools like 'connect' (which likely initiates the login) or 'multi_gmail_connect_finish', so it loses one point for lack of sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides sequential guidance: 'After success, run `set_signer`, then `fetch`.' This implies a usage order but does not explicitly state when to use this tool vs alternatives (e.g., 'connect'), nor does it mention prerequisites like having initiated the login process first. The 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It explains default behaviors (quoteOriginal, appendSignature) and format selection. However, it omits error scenarios, return values, and whether drafts are created vs updated, limiting 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the purpose and key defaults, with no redundant text. The structure is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter tool with no output schema, the description is incomplete. It explains core behavior but omits half the parameters, error handling, and return format, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add value. It covers messageId, to, subject, body, format, quoteOriginal, and appendSignature, but only partially. Missing cc, bcc, html, accountAlias, chatScope, and body is incorrectly stated as required, contradicting the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves or updates a Gmail draft reply for a thread without sending, which distinguishes it from send tools. However, it does not explicitly differentiate from the sibling tool 'set_draft' which likely handles single-account drafts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists required parameters but provides no guidance on when to use this multi-account version vs alternatives. It does not explain context or exclusions, leaving the agent to infer usage from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It lists what is verified and that it suggests next actions, but doesn't disclose side effects, performance implications, or details about the suggested actions. Some transparency, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key actions, with no wasted words. It is efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two undocumented parameters and no output schema or annotations, the description is incomplete. It fails to explain what the parameters are for or what the return value looks like, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the tool description does not explain the parameters 'accountAlias' or 'chatScope'. The description adds no meaning beyond the schema, leaving the agent to infer their roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The title 'Check setup health in one command' and description list specific checks (credentials path, accounts storage, reminders store, active account binding) with a clear verb and resource. It distinguishes itself from sibling tools by focusing on a comprehensive health check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool compared to alternatives like 'diagnostics' or 'status'. The description only states what it does, not the specific context or conditions for use.
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, and the description does not disclose any behavioral traits such as side effects, permissions, or scope of changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of annotations or output schema, the description covers basic purpose but misses details on how 'chatScope' is used and how this differs from the sibling 'set_mode'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description should explain all parameters. It names 'mode' and 'chatScope' but only describes 'mode' via inline options, leaving 'chatScope' unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets response style for a chat with two options. However, it does not differentiate from the sibling tool 'set_mode' which likely serves a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to choose response mode) but does not provide when-not or alternatives like 'set_mode'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the interval semantics of daysList in detail, which is crucial behavioral info. However, it omits how updates work (replace/merge), what pattern does, and does not address the behavior of other parameters. Since no annotations exist, the description carries the full burden but only partially fulfills it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an example, which is relatively concise. The example adds clarity but may be slightly verbose. Overall, it is front-loaded with the core purpose and one key behavioral detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no output schema, and no annotations, the description should cover more. It does not explain return values, error cases, prerequisites, or what 'pattern' means. The absence of guidance on thread identification (messageId) and optional parameters leaves the tool incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 2 of 8 parameters (daysList, pattern) are described in the text. The schema lacks parameter descriptions (0% coverage), so the description must compensate. It fails to explain messageId, businessDaysOnly, dueWeekday, createGmailDraft, accountAlias, chatScope, leaving significant ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or updates follow-up reminders for a thread, specifying the main parameters (daysList, pattern) and the action (create or update). It distinguishes between the two modes, which is essential for selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'update the existing open follow-up plan' but does not provide guidance on when to use this tool versus sibling tools like followup_cleanup, followup_due, or followup_send. No explicit when-not or alternatives.
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 full burden. It mentions 'for this session' indicating session-level scope but does not disclose other behavioral traits such as whether the setting persists across sessions, what happens if called multiple times, or side effects. The advanced note about README is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core action. It provides the essential purpose, usage timing, and an advanced note without excessive verbosity. Well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and four parameters with moderate complexity, the description covers the primary function and timing but lacks information about return values, error conditions, or prerequisites beyond login. It is adequate but not fully exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It explains that 'name' is the display name for reply drafts, 'followUpLabel' is the Gmail follow-up label, and 'accountAlias'/'chatScope' are advanced parameters for multi-account scenarios. This adds context, but does not detail constraints like length or pattern from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves the display name for reply drafts and optionally a follow-up label. The verb 'saves' and resource 'display name used on reply drafts' are specific. However, it does not explicitly differentiate from the sibling 'set_signer' tool, though the name suggests multi-account scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a usage context: 'Call after login when the user says how they want to sign.' This provides guidance on when to use the tool but does not explicitly state when not to use it or mention alternatives among sibling 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?
No annotations are provided, so the description carries the full burden. It explains that quoteOriginal appends Gmail-style quoted parent history and appendSignature appends the account signature, adding some behavioral context. However, it does not disclose side effects (e.g., overwriting existing drafts), authentication needs, or rate 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, with the first sentence front-loading the purpose. Every sentence adds value, and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no output schema, and no annotations, the description is insufficient. It does not explain the purpose of many parameters (cc, bcc, html, accountAlias, chatScope), nor the return value or side effects. A more complete description would cover all parameters and expected output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description adds meaning for 4 parameters (format, quoteOriginal, appendSignature) but leaves 8 parameters unexplained, including the confusing 'html' parameter and the 'body' parameter (which it says is required but is not in schema). It partially compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Save/update a Gmail draft reply for a thread without sending.' It specifies the verb (save/update) and resource (Gmail draft reply), and distinguishes from sending tools among siblings. However, it does not explicitly differentiate from other draft-related siblings like fetch_drafts or multi_gmail_set_draft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'without sending' implying when to use, but it inaccurately lists 'body' as required when the schema only requires messageId, to, and subject. It provides no explicit guidance on when not to use this tool or alternatives, such as when to use send or fetch_drafts instead.
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 exist, so description must carry full burden. It only states 'lists the latest messages' without specifying ordering, count limit, or pagination. Lacks detail on what 'latest' means and does not disclose any restrictions beyond lack of filters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first covers deprecation and alternative, second covers basic function. Front-loaded but omits crucial parameter details, making it incomplete rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with no output schema or annotations, description fails to cover parameter semantics and behavioral details. Overall incomplete for effective tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description must explain parameters. It mentions none of the three: maxResults, accountAlias, chatScope. No guidance on how they affect behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists messages in Gmail Sent folder and identifies itself as deprecated, explicitly distinguishing from the preferred alternative multi_gmail_fetch. Verb 'list' and resource 'Gmail Sent' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Deprecated — prefer multi_gmail_fetch with queryMode=raw and a Gmail query' and clarifies that this tool lacks date/query filters, providing clear when-to-use and when-not-to-use guidance.
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 provided, so description bears full burden. It lists output fields but does not disclose behavioral traits like read-only nature, authentication requirements, side effects, or whether it makes network calls. A read status tool should explicitly state it is safe and non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first enumerates output fields, second gives usage advice. No fluff, all sentences add value. Front-loaded with what it does, then when to use it. Appropriate length for a simple status tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two optional parameters and no output schema. Description lists output fields but does not explain how parameters affect output, return format, or any constraints. For a status tool that can be filtered by account or chat scope, this omission leaves the agent guessing about parameter effects and response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the tool description does not explain either parameter (accountAlias, chatScope). The listed output fields (e.g., 'account connection') hint at accountAlias role, but no explicit mapping or usage guidance. Description adds no value beyond schema for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states what the tool shows (account connection, signer, inbox batch, follow-ups, paths) and suggests it as a first step. Title reinforces 'Workspace summary'. Distinguishes from sibling tools which are specific actions, making it clear this is an overview tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description says 'Use this first when unsure what to do next', providing clear context and a usage condition. However, it does not explicitly state when not to use it or mention alternatives, though the context of many siblings implies it is a starting point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the non-obvious interval behavior of 'daysList' (cumulative intervals after each follow-up), which adds significant behavioral clarity. However, it omits other side effects like email sending or thread modification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus an example, front-loading the purpose. It could be slightly more efficient, but it is not verbose and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and no annotations, the description is incomplete. It lacks explanations for most parameters, return values, and important context like multi-account scope (despite the tool name).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, requiring the description to explain parameters. Only 'daysList' is elaborated with an example; 7 out of 8 parameters (e.g., 'pattern', 'businessDaysOnly', 'accountAlias') receive no semantic explanation, leaving the agent underinformed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: creating or updating follow-up reminders for a thread using 'daysList' or 'pattern'. It is specific about the action and resource, distinguishing it from read-only or cleanup 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/5Does 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 sibling tools like 'followup_trigger' or 'followup_send'. It does not mention alternatives, 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 must fully disclose behavior. It states the tool shows information, implying a read-only operation, but provides no details on side effects, permission requirements, or what happens when optional parameters are provided. The lack of output schema further obscures the behavior. The description is insufficient for an agent to fully understand the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long: the first efficiently lists the displayed information, and the second provides actionable usage guidance. Every word serves a purpose, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description adequately covers purpose and usage context. However, the complete omission of parameter semantics and minimal behavioral detail (no annotations) leave gaps. It is minimally viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two optional parameters (accountAlias, chatScope) with 0% description coverage. The description does not explain their purpose or how they affect the output. Despite listing the information shown, it fails to map parameters to behavior, leaving the agent without guidance on parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows specific workspace summary information: account connection, signer name, last inbox batch, due follow-ups, and local paths. The verb 'shows' and listed resources are precise, and the title 'Workspace summary' reinforces the purpose. It distinguishes itself from siblings like 'fetch' or 'followup_due' by providing a consolidated overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to use this tool first when unsure what to do next, providing clear context for its usage as an initial diagnostic step. However, it does not mention when not to use it or provide explicit alternatives, which would make it more comprehensive.
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 full transparency burden. It discloses the core behavior (removes INBOX label) and source dependencies, but omits details like whether changes are reversible, required permissions, or side effects on other labels.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences, each adding value. However, it could be structured to include parameter explanations without adding much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple archive tool with low complexity, the description covers the core action and threadId source. However, it lacks output/return value description and does not leverage the opportunity to compensate for missing annotations or schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description should explain all parameters. It only addresses threadId (source), but does not define accountAlias or chatScope, leaving their purpose unclear. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (archive a Gmail thread) and the mechanism (removing INBOX label). It distinguishes from sibling tools by specifying 'for the active account', contrasting with multi-account variants. The source of threadId is also mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives implicit usage guidance by stating the context (active account) and recommended threadId sources, but does not explicitly state when to use this tool over alternatives like multi_gmail_archive or when not to use it.
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 present, so description is the sole source. States it lists drafts, which is a read operation, but does not mention safety, permissions, or any side 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with core purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and three undocumented parameters, the description is insufficient. It lacks parameter details, return format, and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention any of the three parameters (maxResults, accountAlias, chatScope). It adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool lists drafts in Gmail Drafts folder, distinguishes from inbox and sibling tools like fetch and fetch_sent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly suggests use case 'Use to review unsent drafts' and implies separation from inbox, but lacks explicit when-not-to-use or alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description minimally conveys that the tool is a read operation (listing) without filters. It does not disclose pagination, rate limits, or return format, but for a simple list tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with the most critical information (deprecation and alternative) front-loaded. Every word adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters and no output schema, the description fails to cover parameter usage or return structure. It only states the basic functionality, which is insufficient for proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description explains none of the three parameters (maxResults, accountAlias, chatScope). There is no guidance on what they do or how to use them, leaving the agent uninformed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists latest messages in Gmail Sent without filters. The deprecation note and reference to multi_gmail_fetch distinguish it from siblings, but the 'latest messages' phrasing is somewhat vague regarding sort order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using multi_gmail_fetch with queryMode=raw and a Gmail query instead, and clarifies that this tool still works but lacks filtering. This provides clear when-to-use guidance and an alternative.
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, and the description does not disclose behavioral traits such as persistence, reversibility, or effect scope beyond 'for this chat scope'. The agent lacks information about the tool's side effects or scope nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the purpose and parameters. It is front-loaded, concise, and contains no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description is minimally adequate but lacks clarity on optional chatScope behavior and does not mention return values or side effects. An agent may be uncertain about using the tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 names the enum values (standard/compact) and mentions 'chat scope', adding some meaning to the mode parameter. However, the chatScope parameter is not explicitly defined, leaving ambiguity about its format or required status.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state that the tool sets the response style (standard or compact) for a chat scope. The verb 'set' and resource 'response mode' are specific, and the tool is distinct from siblings like 'set_draft' or 'set_signer'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for choosing between standard and compact modes, but lacks explicit guidance on when to use this tool versus alternatives or when not to use it. It does not mention defaults or conditions.
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 provided, so description carries the burden. It mentions 'refresh thread state' (mutation) and returns full context, but does not disclose side effects like whether reminders are marked as seen or if state changes are permanent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with front-loaded purpose and key usage guidelines. No superfluous text, but slightly more detail could be added without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and parameter semantics missing. The description covers purpose and usage but lacks prerequisites, parameter meaning, and expected output format. For a tool interacting with email state, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description does not mention the two parameters (accountAlias, chatScope). Schema description coverage is 0%, and no parameter details are added, leaving the agent without guidance on how to set these fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists reminders due now, refreshes thread state, and returns full thread context. It distinguishes from siblings like followup_trigger and followup_send by focusing on listing due reminders for review.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to present drafts for proof-reading before sending and never call followup_send without approval. This provides clear when-to-use and when-not-to-use guidance beyond just the tool function.
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 must disclose behavioral traits. It indicates a read operation but does not detail authentication needs, rate limits, or behavior with multiple accounts. Adequate for a list tool, but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the main purpose, and contains no filler. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no parameter descriptions leave gaps. While the tool is simple, the lack of parameter semantics makes it incomplete for an agent to use effectively without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no explanation of parameter meanings (maxResults, accountAlias, chatScope). The agent must rely solely on parameter names, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists drafts in Gmail Drafts folder, explicitly separates from inbox, and indicates use case for reviewing unsent drafts. It effectively distinguishes from sibling tools like fetch_drafts by implying multi-account capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Separate from inbox' and 'Use to review unsent drafts,' providing context for when to use this tool. However, it does not explicitly compare to alternatives like multi_gmail_fetch or fetch_drafts, or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses side effects: 'marks source read, threads send.' It explains default behaviors for quoteOriginal and appendSignature. However, it lacks details on irreversibility, immediate sending behavior, or auth requirements. Given no annotations, the description carries the full burden but misses some important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 5 sentences. It front-loads the purpose, then systematically explains key parameters and their defaults, and ends with a usage warning. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, 3 required, no output schema), the description is incomplete. It does not explain the return value, error conditions, or behavior for all parameters. Important fields like 'to' and 'subject' are left undiscussed, and the overall sending mechanism (e.g., synchronous, queued) is not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates partially by explaining 6 of 12 parameters (messageId, body, format, html, quoteOriginal, appendSignature). Critically, it omits descriptions for required parameters 'to' and 'subject', as well as 'cc', 'bcc', 'accountAlias', and 'chatScope'. This leaves significant gaps for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Send one approved reply' and specifies the required messageId. It distinguishes from the sibling tool 'send_new' by explicitly stating 'For new outbound / campaigns use send_new instead.' The verb and resource are specific, and the scope (replying) 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using 'send_new' for new outbound emails, providing a clear alternative. It also warns 'Never run without explicit approval.' However, it does not address when to use this tool versus multi-account variants (e.g., multi_gmail_send), which are present 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It conveys that the tool creates labels and implies it is safe to run even if labels exist (by saying 'create... if missing'). It mentions potential auth issues but does not discuss idempotency, rate limits, or exact permissions needed beyond gmail.modify.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise, with two sentences explaining purpose and a second paragraph for usage guidance. However, the second paragraph includes a npm command and additional details that slightly reduce conciseness. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, output schema, or parameter descriptions, the description covers main use and a specific troubleshooting case. It lacks information about return values, error handling, or what happens when labels already exist. It is minimally complete for a simple setup tool but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It only states 'Pass accountAlias / chatScope like other Gmail tools,' which provides no independent explanation of what these parameters represent or their format. This is insufficient for an agent to understand parameter usage without external context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates specific Gmail user labels (FOLLOW_UP_GMAIL_LABEL_*, GMAIL_REVIEW_GMAIL_LABEL_*) using the Gmail API. It distinguishes from sibling tools by focusing on label setup, not fetch, send, or other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: if labels did not appear after connect or fetch, and even provides troubleshooting for missing gmail.modify scope. It does not, however, compare directly to sibling tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description transparently outlines the workflow steps shown. No hidden side effects or destructive actions implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently conveys the tool's purpose and workflow steps without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and a help-only function, the description adequately covers the tool's role and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; baseline score of 4 applies since the description adds no param info needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it shows setup and a recommended workflow, listing steps. It distinguishes from sibling action tools like fetch or send.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied use for first-time setup and learning the workflow, but no explicit when-not-to-use or alternatives mentioned.
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 must disclose behavioral traits. It explains that reminders are removed from the local store and optionally removes the Gmail label when no reminders remain. However, it does not clarify whether operations are irreversible, affect server data, or require specific permissions, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) and front-loads the primary action. It efficiently conveys key usage patterns without extraneous details. A slightly more structured format (e.g., bullet points) could improve readability, but it is concise enough to be quickly parsed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no output schema, and no annotations, the description covers the main functionality but lacks details on return values, error handling, or behavior when no reminders match. It adequately describes the tool's primary purpose but leaves some contextual gaps for complex usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds critical meaning. It explains the purpose of eight key parameters: 'reminderIds', 'messageId', 'messageHeaderId', 'sourceThreadId', 'followUpChainId', 'cancelChain', 'deleteAll', and 'confirm'. It describes special behaviors like chain cancellation and bulk deletion. However, it omits 'statuses', 'accountAlias', 'chatScope', and 'removeGmailLabel' (implied but not detailed), so not all parameters are fully covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes follow-up reminders from the local store, with a specific verb ('Remove') and resource ('follow-up reminder(s)'). It also mentions an optional Gmail label removal. The name 'multi_gmail_followup_cleanup' distinguishes it from sibling 'followup_cleanup', and the description implies multi-account support via the 'accountAlias' parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists ways to identify reminders and special options like 'cancelChain' and 'deleteAll' with 'confirm', providing some usage guidance. However, it does not explicitly compare to sibling tools (e.g., 'multi_gmail_followup_trigger', 'multi_gmail_followup_due') or state when not to use this tool, limiting its usefulness for choosing the right tool.
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 exist, so description must disclose behavior. It mentions automatic RFC 2047 encoding for German/Unicode subjects and support for htmlBody legacy. But it lacks details on sending limits, error handling, or what 'explicit approval' entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, front-loaded with key conditions (no messageId, threadId usage). Each sentence adds value, though the approval warning could be more specific.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters and no output schema, the description covers essential usage but omits many optional parameters and doesn't explain return values or error scenarios. Missing details on approval process and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds context for to, subject, body, format, htmlBody, and threadId, which are a subset of 10 parameters. It explains format defaults and encoding, but cc, bcc, accountAlias, chatScope are not mentioned. Schema lacks descriptions, so partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sends a new outbound email for campaigns and cold outreach, distinguishes from siblings by specifying no messageId, and explains the optional threadId for continuing threads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions use for campaigns/cold outreach, when to use threadId (campaign email 2+), and warns to not run without approval. However, it doesn't explicitly contrast with the sibling 'multi_gmail_send' tool for replies.
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 must carry the full burden. It lacks details on side effects (e.g., overwrites previous signer), persistence scope, error handling, or authentication requirements beyond login timing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each serving a purpose: core function, timing, advanced usage. No redundant text, but could be more streamlined by integrating the advanced note into the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main purpose and parameter semantics, but lacks information on return values, error conditions, session lifecycle, and differentiation from closely related tools like multi_gmail_set_signer, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by explaining that 'name' is the display name, 'followUpLabel' is the Gmail follow-up label, and advanced parameters are for multi-account or shared-session, adding meaning beyond the schema's technical constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves the display name used on reply drafts for the session, which is a specific verb+resource combination. It distinguishes from siblings like set_draft or set_mode by focusing on signer name for replies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call after login when the user says how they want to sign', providing clear timing and trigger. Mentions advanced parameters for multi-account scenarios, offering some guidance, but doesn't directly contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behaviors: re-checks thread, blocks if customer replied, and details optional overrides with defaults. Missing details on return value, error conditions, or authentication requirements, but the core behavioral traits are well-covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences) and front-loaded with purpose. The important usage note is highlighted. It efficiently conveys the core purpose and key options, though some parameter explanations are omitted which could be included without bloating.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 parameters, no output schema, no annotations), the description provides essential context but lacks parameter-level detail for many fields. It also does not describe the return value or error handling, which are important for a send operation. It partially compensates with the explicit constraint and default values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It covers only about 5 of 12 parameters (body, format, quoteOriginal, appendSignature, and implicitly reminderId). Many important parameters (to, subject, cc, bcc, html, accountAlias, chatScope) are not described, leaving the agent with incomplete guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('send') and resource ('one approved follow-up reminder'), with specific behavioral details like re-checking the thread and blocking if customer replied. It effectively distinguishes this tool from siblings like 'followup_cleanup' and 'followup_trigger'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit usage constraint: 'NEVER call without explicit user approval after showing the draft.' It also outlines the pre-condition of re-checking the thread. However, it lacks explicit guidance on when to use this tool versus its siblings (e.g., 'followup_due' or 'multi_gmail_followup_send'), though the purpose itself implies a specific scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behaviors: re-checks the thread, blocks if customer replied, and lists optional overrides with defaults. It does not mention success/failure responses or side effects, but 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—three sentences that cover purpose, behavior, and a critical warning. It is front-loaded with the main action and uses formatting for emphasis. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no schema descriptions, and no output schema, the description is incomplete. It omits details on essential parameters like 'to', 'subject', 'cc', 'bcc', and 'accountAlias'. The safety behavior and approval requirement are good, but overall completeness is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It only mentions a few optional overrides (body, format, quoteOriginal, appendSignature), leaving 8 other parameters (including required reminderId) completely undescribed. This is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Send') and resource ('one approved follow-up reminder'). It specifies the unique behavior of re-checking the thread and blocking if the customer replied, which distinguishes it from sibling tools like multi_gmail_send or multi_gmail_followup_trigger.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a critical usage constraint: 'NEVER call without explicit user approval after showing the draft.' This gives clear context on when to use the tool. However, it does not explicitly compare with alternatives or state when not to use it, which would improve the score.
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 must convey behavioral traits. It only states it returns aliases, but lacks details on whether it reads files, authentication needs, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, front-loaded with the key action 'Returns token file aliases (strings).' Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description sufficiently explains the tool's function and usage for a simple list tool. Minor gap: no mention of listing scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description adds meaning by explaining the purpose of the output, exceeding the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns token file aliases (strings) and explains their use as accountAlias on other tools, distinguishing it from siblings by its specific role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Pass one as accountAlias on other tools when the MCP client shares one default session across chats.' Does not mention when not to use, but context is clear.
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 bears full responsibility. It explains deletion, chain cancellation, bulk deletion, and optional Gmail label removal. However, it does not disclose irreversibility, error cases, or side effects beyond label removal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph with multiple sentences, packing considerable detail. It is relatively concise but could be improved with structural elements like bullet points for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no annotations, and no output schema, the description covers core functionality and usage modes. Missing details include return value, error scenarios, and prerequisites (e.g., account connection), but overall it is sufficient for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It mentions most parameters (reminderIds, messageId, etc.) and explains their roles (e.g., cancelChain works with reminderIds). Although it groups them, it adds significant meaning beyond the schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Remove follow-up reminder(s) from the local store,' which clearly states the verb and resource. It distinguishes from siblings like followup_due, followup_send, and followup_trigger by focusing on deletion rather than triggering or sending.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage patterns: pass specific IDs, use cancelChain to drop chains, or use deleteAll with confirm. It implicitly guides when to use each parameter, but does not explicitly state when NOT to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that format=full returns plain-text message bodies, explains the stripped parameter's effect on quoted history, and instructs to present message.text verbatim. It does not cover authorization or rate limits but is transparent about core behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads the core purpose, and every sentence adds specific value (usage context, format details, verbatim instruction). No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no output schema, the description explains key but not all parameters. It omits accountAlias and chatScope, and does not describe the return structure beyond 'plain-text message bodies.' The format=metadata option is unmentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains threadId, format (with enum and default), stripped (boolean with behavior), and hints at latestN. However, accountAlias, chatScope, and includeRaw are not described, leaving gaps for parameters that may be important for multi-account scenarios.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads one Gmail thread at a time, specifies it is for use after fetch mode=list, and explains the different format options and stripped behavior. It distinguishes from siblings by indicating this is per-thread and not for batch operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context: 'use after fetch mode=list' and 'Call separately per thread.' It also warns against summarizing. However, it does not explicitly exclude scenarios or compare to sibling tools like multi_gmail_get_thread.
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?
Reveals the core behavior (removing INBOX label) despite no annotations. Missing details on permissions, side effects on other labels, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with clear action and ancillary usage note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers what, how, and where to get input, but omits error conditions, handling of optional parameters, and distinctions from similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; description does not explain accountAlias or chatScope parameters. Only threadId is implied via usage guidance. Barely adds meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States explicitly that it archives a Gmail thread by removing the INBOX label, and ties it to specific parameter sources. Clearly distinguishes the action and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on sourcing the threadId from fetch, followup_due, or get_thread, but does not differentiate from the sibling 'archive' tool or specify when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses approval requirement, auto-encoding of subjects, support for HTML format and legacy htmlBody, and threading behavior. Lacks details on error handling or rate limits but covers key traits for a send operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph with clear logical flow: purpose, use case, requirements, encoding, body format, legacy support, safety warning. Front-loaded and no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core aspects (purpose, key parameters, threading, approval) but misses details on less common parameters (cc, bcc, accountAlias, chatScope) and does not mention return value. For a 10-parameter tool with no output schema, description is moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. Adds meaning for required parameters (to, subject), body/format/htmlBody, and threadId. Does not explain cc, bcc, accountAlias, or chatScope. Partial compensation but not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sends a new email (not a reply) for campaigns and cold outreach, distinguishes from siblings by specifying 'no messageId' and mentioning threadId for chaining, which contrasts with a typical reply tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (campaigns, cold outreach) and when not to (explicit approval required). Gives context for threadId usage. Does not explicitly name sibling tools but implies when not to use via 'no messageId'.
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 fairly discloses the open-browser behavior and the need for user approval. It doesn't mention any destructive actions or permissions, but for an auth initialization tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the purpose, provide usage examples, and state next steps. No fluff; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers the core workflow effectively. The only missing piece is the 'chatScope' parameter, but overall it's sufficient for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the 'command' parameter via examples (e.g., 'you@example.com personal'), but does not explain the 'chatScope' parameter at all. Schema coverage is 0%, so description partially compensates but leaves a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it starts Gmail login, provides example commands, and distinguishes from siblings like connect_finish. The verb 'connect' is specific to initiating authentication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use (to start login) and the immediate next step (run connect_finish). It implies a workflow but doesn't specify when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that list mode returns lightweight metadata, full mode batch-loads and auto-drafts (token-heavy), and that nothing is sent automatically. However, it doesn't cover rate limits or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph that front-loads the recommended mode and provides specific, actionable advice without unnecessary verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers usage scenarios well, it leaves several parameters undocumented and does not address multi-account handling (given siblings like multi_gmail_fetch). Given 9 parameters and no output schema, more detail would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description should explain all 9 parameters. It only covers mode, queryMode, and implies query behavior, leaving maxResults, includeLatestBody, saveGmailDrafts, writeMarkdownFile, accountAlias, and chatScope unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists inbox threads or batch-fetches with specific output details (subject, snippet, threadId). It distinguishes between list and full modes, and differentiates from sibling 'get_thread' which retrieves full email bodies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: recommend default list mode, advise against full mode for normal inbox review, specify when to use queryMode=raw vs inbox, and direct users to call get_thread for full bodies. It also warns against loading multiple full threads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that browser opens for user approval, which is key behavioral insight. Does not cover rate limits or permissions, but acceptable for a login 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Purpose is front-loaded. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and presence of sibling 'connect_finish', description adequately explains flow. Could mention error handling or prerequisites, but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 2 parameters with 0% description coverage. Description adds meaning by showing command format ('Connect you@example.com personal'), implying command includes email and scope, but does not explicitly define each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts Gmail login, with specific example commands ('Connect you@example.com personal' or 'work'). It distinguishes from sibling tools like 'connect_finish' by mentioning it as the next step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: browser opens for approval, then run 'connect_finish'. Includes example commands. Does not explicitly state when not to use, but clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that snippets are not full bodies, that full mode batch-loads and auto-drafts (token-heavy), and that nothing is sent automatically. It does not cover rate limits or auth but is otherwise transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise, front-loading the recommendation and key constraints. Some redundancy exists (e.g., 'Nothing is sent automatically' repeats from param descriptions). Still, it remains readable and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters and no output schema, the description covers the core use case well, explaining modes, query modes, and key behavioral constraints. However, it omits details on many parameters and does not describe the output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description explains mode and queryMode enums but does not cover 7 other parameters (maxResults, includeLatestBody, saveGmailDrafts, writeMarkdownFile, accountAlias, chatScope, query). Only 2 of 9 parameters get semantic explanation, insufficient for full understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists inbox threads or batch-fetches. It distinguishes modes (list vs full) and recommends list for triage, effectively differentiating from sibling tools like fetch, get_thread, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: uses list for triage, advises to use get_thread for full bodies, warns against full mode for normal review, and explains queryMode for sent/archives. Also tells agents not to summarize or load multiple full threads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully discloses behavior: loads one thread, returns plain-text bodies, format options, stripped behavior, and instructs to present verbatim without summarizing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 4 sentences, front-loads purpose and key usage, and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite good purpose and transparency, the description omits details for several parameters (latestN, includeRaw, accountAlias, chatScope) and does not explain return values, making it incomplete for a tool with no output schema and no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains format and stripped well, but does not cover latestN, includeRaw, accountAlias, or chatScope, leaving gaps for a 7-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it loads one Gmail thread as a clean transcript, specifies usage after fetch mode=list, and distinguishes from siblings like multi_gmail_fetch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context for when to use (after fetch mode=list) and instructions for stripped and format parameters. However, it lacks explicit when-not-to-use guidance versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It discloses key behaviors: marks source as read, threads the send, appends Gmail signature and quoted original, and supports legacy 'html' parameter. However, it omits details like whether sending is immediate, error handling, or rate limits, which would improve transparency. Still, the coverage is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of about 4 sentences, which is concise. It front-loads the core purpose and key parameter behaviors. However, the structure could be improved by separating parameter details from flow instructions, and the sentence about legacy `html` could be merged. Still, it is efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 params, 3 required, no output schema, no annotations), the description covers the essential purpose and parameter behaviors but lacks explanation for several optional params and does not describe the return value or error behavior after sending. For a critical action like sending email, this is a gap, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 explains `messageId`, `body`, `format`, `quoteOriginal`, `appendSignature`, and legacy `html`. However, it does not explain `to`, `subject`, `cc`, `bcc`, `accountAlias`, or `chatScope`, leaving 6 out of 12 parameters undocumented. While some are self-explanatory, the missing explanation for `accountAlias` and `chatScope` lowers the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Send one approved **reply**' and explicitly contrasts with 'send_new' for new outbound/campaigns, clearly distinguishing the tool's purpose as a reply-only function. The verb 'send' and resource 'reply' are specific, and the sibling tool 'send_new' is named for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'Requires `messageId` (marks source read, threads send)' and 'For new outbound / campaigns use `send_new` instead.' It also warns 'Never run without explicit approval.' This provides explicit when-to-use and when-not-to-use guidance, including an alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses that this tool creates labels and requires certain OAuth scope (gmail.modify). Could mention idempotency or behavior if labels already exist, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is informative but a bit verbose; could be more concise. Front-loaded with main action, but includes troubleshooting details that might be better elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple label creation tool, description covers purpose, usage trigger, and parameter pattern. No output schema, but return value may be obvious. Could mention success/failure cues.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description only mentions parameter names (accountAlias, chatScope) without describing their purpose or expected values, relying on 'like other Gmail tools' assumption.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it creates specific Gmail labels (FOLLOW_UP, REVIEW) so they appear under Labels. It distinguishes from sibling setup_labels (non-multi) and other 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says use if labels didn't appear after connect/fetch, and provides troubleshooting for missing gmail.modify scope. Also instructs to pass accountAlias/chatScope like other Gmail tools.
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?
Without annotations, description carries full burden. It states tool returns aliases (strings) with no side effects. It doesn't mention authentication or file reading, but for a simple list operation this is sufficient 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Information is front-loaded: first sentence states what it does, second explains how to use the output. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, description fully covers purpose and integration with sibling tools. An agent would understand exactly what to expect and how to use the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so baseline is 4. Description adds value beyond schema by explaining the nature of returned values and their usage in other tools, making it highly informative.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Title and description clearly state tool returns token file aliases for saved Gmail accounts. It explains the output are strings. While it doesn't explicitly differentiate from sibling multi_gmail_accounts, the context is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides specific guidance: pass the alias as accountAlias on other tools when MCP client shares one default session. This gives clear context for when to use the tool, though it does not list alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries full burden. It discloses the tool is informational (shows setup and workflow). No contradictions or hidden behaviors noted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with purpose, all words add value. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a help walkthrough tool with no parameters or output schema, the description completely explains what it does and the workflow it covers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description does not need to add param details. Baseline of 4 applies and the description is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows setup and the recommended inbox workflow, listing specific steps. It distinguishes itself from sibling tools (e.g., multi_gmail_fetch, multi_gmail_get_thread) by being a walkthrough/guide.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for first-time setup and workflow guidance. It does not explicitly state when not to use it, but the context of sibling tools suggests this is a non-action guide.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/japan08/MCP-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server