Read, search, draft, send, and organize email across Gmail, Outlook, and IMAP mailboxes. Connect over Streamable HTTP with OAuth and choose which mailboxes and permissions each agent can access.
Scored across 16 tools
Each tool has a distinct resource and action: drafts use create/get/update/delete, emails use list/get/modify, and sending uses preview/send/delivery operations. The only mild overlap is attachment metadata appearing in both get_email and download_attachment, but their primary purposes are clearly separated.
All tool names use consistent snake_case with a clear verb_noun pattern, such as create_draft, list_emails, and get_delivery_operation. No mixed conventions or vague one-word names appear.
16 tools is slightly above the typical ideal range, but each tool covers a meaningful mail operation. The count is reasonable for a feature-rich email client with drafts, sending, search, labels, folders, and attachments.
Core email workflows are covered: draft CRUD, listing/searching mail, thread reading, sending, previewing, delivery checks, and attachment download. Minor gaps exist around creating/deleting folders or labels and explicit reply/forward operations, but agents can work around these for most tasks.
Create a draft in the mailbox.
| Name | Required | Description | Default |
|---|---|---|---|
| cc | No | ||
| to | No | ||
| bcc | No | ||
| from | No | ||
| subject | No | ||
| bodyHtml | No | ||
| bodyText | No | ||
| replyAll | No | ||
| accountId | No | ||
| attachments | No | ||
| replyToMessageId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that – no note on where the draft lands, whether it is persisted server-side, or what happens with replyToMessageId. It contributes no behavioral context of its own.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence that is front-loaded and free of padding, so it is structurally clean. But the brevity here reflects under-specification rather than disciplined conciseness, since it omits information an 11-parameter tool needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter, zero-required, mutation tool with no output schema and no per-parameter descriptions, this description is far too thin. An agent cannot tell what a draft requires, what the reply fields do, or how attachments and account targeting work.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 11 parameters, including non-obvious ones like replyAll, replyToMessageId, accountId, and the attachment content/contentId/disposition fields. The description compensates for none of this, leaving half the schema's semantics (boolean and id relationships) undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Create a draft'), so the operation is unambiguous. However, it does nothing to distinguish itself from siblings like update_draft, preview_send, or send_email, which an agent must choose between.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no mention of prerequisites (e.g. accountId selection), and no reference to alternatives such as update_draft for editing or send_email for dispatching. The agent is left to infer the workflow entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a mailbox draft.
| Name | Required | Description | Default |
|---|---|---|---|
| draftId | Yes | ||
| accountId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds nothing beyond them – it does not say whether the delete is permanent or moves to trash, nor any auth/account scoping requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler or redundancy. It is efficient, though its brevity comes partly from omitting information rather than from tight editing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, open-world mutation tool with two undocumented parameters and no output schema, the description leaves key questions open: which account the draft belongs to, whether deletion is reversible, and what happens to a non-existent draftId. Annotations cover the safety hint but not the operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and neither draftId nor accountId is explained anywhere. The word 'draft' loosely implies a draftId, but the agent gets no information about whether accountId is required to scope the mailbox or what format identifiers take.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Delete) and resource (mailbox draft), which cleanly separates it from create_draft, get_draft, and update_draft in the sibling list. It does not explicitly name or differentiate against siblings, but the action itself is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus update_draft (e.g., editing contents) or get_draft, and no preconditions such as whether the draft must exist or whether it is recoverable. The agent must infer the use case from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata and a resource link for one attachment, up to 10 MB. With inline, the result also includes the content.
| Name | Required | Description | Default |
|---|---|---|---|
| inline | No | ||
| accountId | No | ||
| messageId | Yes | ||
| attachmentId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description does add real behavioral context beyond them: the 10 MB limit and the fact that 'inline' changes the payload to include content. It still omits what happens when an attachment exceeds 10 MB, whether the resource link is a URL with an expiry, and any auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action and immediately followed by the size constraint and the inline behavior. No filler or restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does useful work in sketching the return (metadata, resource link, optional content), but it leaves the meaning of accountId and the failure mode for oversized attachments undefined. For a 4-parameter download tool with zero schema documentation, that is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden and explains only one of four parameters ('inline'). accountId is completely unexplained (which account? required for multi-account?), and messageId/attachmentId are left to their names alone to convey scope and source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get metadata and a resource link for one attachment') and adds a size cap and the inline variant. An agent can tell this is attachment-scoped rather than message-thread scoped, though it never explicitly contrasts with siblings like get_email or get_thread that also return attachment data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no mention of prerequisites (e.g. the message/attachment must already exist or how to discover an attachmentId), and no routing against alternatives such as get_email for locating attachments. The agent must infer the calling context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the saved result of a send, including an uncertain outcome.
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | Yes | ||
| operationId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds a modest hint that a send may have an 'uncertain outcome,' but it does not explain eventual consistency, polling behavior, or how an uncertain/ambiguous state should be interpreted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no filler, and the core action is front-loaded. It is efficient, though the brevity reflects under-specification rather than disciplined trimming.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the full burden of describing what the 'saved result' contains, yet it never states the return shape, possible status values, or what makes an outcome 'uncertain.' Combined with undocumented parameters, it is not complete enough to call the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for both required parameters, so the description needs to compensate and does not. It never clarifies what accountId or operationId are, where operationId comes from, or their format, leaving the 512-char string identifiers entirely opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource — checking the saved result of a send — which tells an agent this is a status/result retrieval tool. It does not explicitly contrast with siblings like get_email or preview_send, and the term 'delivery operation' from the name is never explained, but the intent is still discernible.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance, no mention of alternatives (e.g., preview_send, send_email), and no indication of whether this should be polled or how it relates to the send flow. Usage is only faintly implied by 'result of a send'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a mailbox draft.
| Name | Required | Description | Default |
|---|---|---|---|
| draftId | Yes | ||
| accountId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context beyond restating 'Read a mailbox draft'—no auth requirements, rate limits, or return behavior are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words. However, it is under-specified for a tool with two parameters, making brevity a weakness rather than a strength.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 0% schema description coverage, the description should carry more context about parameters, usage, and behavior. It omits these entirely, leaving the agent with only the tool name and annotations to work from.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for two undocumented parameters. It mentions neither draftId nor accountId, leaving parameter meaning entirely to the schema's type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Read a mailbox draft.' It distinguishes the resource type (draft) from sibling tools like get_email and get_thread. However, it does not differentiate further from other draft tools such as create_draft, update_draft, or delete_draft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. Usage is only implied by the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read an email and its attachment metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | No | ||
| messageId | Yes | ||
| includeHeaders | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and open-world behavior are covered. The description adds that attachment metadata is included in the result, which is useful content-level context, but says nothing about body format, whether headers appear by default, or result size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the core action front-loaded and no filler. It is efficient, though its brevity contributes to the missing usage and parameter detail scored elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple annotated read tool with no output schema, the definition is minimally viable but thin: it omits parameter meaning, body/header behavior, and any relation to the attachment-download sibling. An agent could call it, but not with confidence about the returned shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for three parameters and supplies none of it. The mention of 'attachment metadata' is only loosely related to includeHeaders, and accountId/messageId scoping (e.g., single-account vs multi-account) is never clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource (read an email) and adds scope detail (attachment metadata). However, it does not distinguish itself from siblings like get_thread or get_draft, which an agent could easily confuse with a single-message fetch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus get_thread, list_emails, or download_attachment. The agent must infer usage purely from the name and the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the messages in an email thread.
| Name | Required | Description | Default |
|---|---|---|---|
| threadId | Yes | ||
| accountId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: no indication of whether the whole thread is returned, ordering, pagination, or the meaning of the openWorld hint for this call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short front-loaded sentence with zero wasted words. It is efficient, though the brevity comes at the cost of the missing detail noted elsewhere rather than being a model of tight completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, two undocumented parameters, and only the name 'thread' to indicate scope, the definition is too thin for an agent to call it confidently or predict the response shape. It should at minimum clarify thread scoping and the accountId parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and both threadId and accountId are undocumented in the schema, so the description carries the full burden. It mentions 'thread' only implicitly and never explains threadId's format or what accountId (optional) selects, leaving the accountId requirement ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Read the messages in an email thread'), so the operation is identifiable. However, it does nothing to distinguish itself from siblings like get_email or list_emails, leaving the agent to infer that this one is thread-scoped rather than message-scoped.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus get_email, list_emails, or list_folders. A reader can guess it is the thread-oriented variant from the name, but the description never states that condition or any prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List connected mailboxes accessible to this connection.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered without the description. The phrase 'connected ... accessible to this connection' adds scoping context, but nothing is said about return format, ordering, or result size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; every word carries scope information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool with no output schema and annotations covering safety, the description is close to sufficient. Slightly thin on what an 'account/mailbox' result represents, but nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there are no semantics to document and the schema is trivially complete. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (connected mailboxes/accounts), which distinguishes it from the other list_* siblings (list_folders, list_labels, list_emails, list_send_as). The name/title mismatch ('accounts' vs 'mailboxes') is minor and resolved by the shared noun in title and description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit when-to-use or when-not-to-use guidance and names no alternatives, even though multiple list_* tools exist. Usage is only faintly implied by 'accessible to this connection'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or search mail with filters and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| from | No | ||
| read | No | ||
| text | No | ||
| after | No | ||
| before | No | ||
| folder | No | ||
| starred | No | ||
| subject | No | ||
| pageSize | No | ||
| accountId | No | ||
| pageToken | No | ||
| hasAttachment | No | ||
| includeSnippet | No | ||
| rawProviderQuery | No | ||
| includeSearchContext | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only a vague mention of filters and pagination, without saying what is returned, how paging works, or any rate/scope limits, so it adds little beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with no wasted words. It is efficient, though its brevity here is part of the under-specification problem rather than a virtue in itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A 16-parameter search tool with no output schema and no parameter descriptions needs substantially more than one sentence. Nothing tells the agent which filters combine, how paging tokens work, or what a result contains, making the definition inadequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 16 parameters with 0% schema description coverage, and the description does not name or explain a single one. With zero structured documentation, the description must carry the burden and it fails completely; an agent cannot tell what 'to', 'read', 'rawProviderQuery', or 'includeSearchContext' do without guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('list or search') and resource ('mail') plus the general mechanism ('filters and pagination'). It does not differentiate from siblings like get_email, get_thread, or modify_emails, so it remains inferable rather than explicit, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus get_email, get_thread, or list_folders, and no mention of prerequisites or account context. 'With filters and pagination' describes the mechanism, not when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the mailbox folders.
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: no word on whether the folder set is flat or hierarchical, whether the list is paginated, or what happens when accountId is omitted, which is the main behavioral question for this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler is structurally fine, but at seven words it is terse to the point of under-specification rather than genuinely efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with an undocumented optional accountId, no output schema, and a crowded sibling namespace, the description leaves the key questions (which account, what the return looks like, how folders relate) unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions the single accountId parameter, so the agent gets no indication of what it does or that it is optional (required=0). It fails to compensate for the documentation gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb and resource ('List the mailbox folders'), so the agent knows the operation immediately. It does not differentiate from siblings like list_labels, list_accounts, or list_emails, leaving room to doubt which listing tool applies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no mention of alternatives (e.g., list_labels for labels rather than folders), and no prerequisites such as whether an accountId is needed or which account is defaulted. The agent must infer all routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List mailbox labels or categories.
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond the name — no information about result set size, ordering, or whether the listing spans all accounts or one mailbox.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no waste, and the core action is front-loaded. It is efficient, though its brevity contributes to the gaps elsewhere rather than being purely economical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with no output schema, the description should at least sketch what is returned or how accountId scopes the result. Instead it offers only the name echoed back, which is insufficient for an agent to call it confidently alongside four sibling list_* tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter (accountId) with 0% schema description coverage, and the description never mentions it. It does not explain whether accountId is required to scope results or what happens when it is omitted, so the description fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ("List mailbox labels or categories"), so the basic action is clear. However, it does not distinguish this tool from the closely related siblings list_folders, list_accounts, list_emails, and list_send_as, leaving the agent to guess how 'labels' differ from 'folders' or what a 'category' is in this mailbox model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this tool versus the many other list_* siblings, nor any stated prerequisite (e.g., whether an account context is needed). The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available sender addresses.
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds nothing beyond that: no note on whether results are scoped to the caller, whether the list is paginated, or what an empty result means.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler. It is concise rather than padded, though the brevity is achieved by omitting needed detail rather than by tight editing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one undocumented parameter, no output schema, and no annotations beyond read-only/open-world, the description leaves an agent unable to predict the scope or shape of results. It should at least clarify the accountId relationship and what a 'sender address' record represents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter (accountId) with 0% schema description coverage, and the description never mentions it. It gives no hint whether accountId narrows the sender list to a single account or is merely optional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('List available sender addresses'), which is unambiguous on its own. It does not differentiate from siblings such as list_accounts, which is a plausible source of confusion about which identity resource to fetch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to call this versus alternatives like list_accounts, nor any prerequisite (e.g. that an account context may be needed). The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change message flags, labels, or folders. Gmail OAuth supports trash and untrash; permanent deletion is unavailable.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| folder | No | ||
| labels | No | ||
| accountId | No | ||
| messageIds | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuine non-annotation context: trash/untrash are supported but permanent deletion is not available for Gmail OAuth, which prevents an agent from attempting an impossible operation. It still omits what 'move' does to a message and what the call returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero filler. The operation scope is front-loaded and the limitation follows immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, open-world mutation with an enum-driven action set and no output schema, the description covers the operation surface and one important platform limitation. It leaves gaps on account selection, batch limits, action/parameter pairing, and result reporting, which the totally undescribed schema does not fill in.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 5 parameters, so the description must compensate and largely does not. It gestures at labels and folders, but says nothing about messageIds (required, 1-100 items), accountId (relevant given the sibling list_accounts), or which action values require which companion parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Change message flags, labels, or folders') that maps cleanly onto the action enum and the folder/labels parameters. An agent can tell it apart from list_emails/get_email, but it does not explicitly differentiate itself from update_draft or delete_draft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the mutation verb, and the second sentence gives one real constraint (permanent deletion unavailable on Gmail OAuth). However, there is no explicit statement of when to prefer this over siblings like delete_draft, nor any prerequisite (e.g., label/folder must pre-exist) for move/addLabels actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate recipients, sender, and attachment limits without sending mail.
| Name | Required | Description | Default |
|---|---|---|---|
| cc | No | ||
| to | No | ||
| bcc | No | ||
| from | No | ||
| subject | No | ||
| bodyHtml | No | ||
| bodyText | No | ||
| replyAll | No | ||
| accountId | No | ||
| attachments | No | ||
| replyToMessageId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true is consistent with the 'without sending mail' claim, so there is no contradiction. The description usefully discloses the three validation categories, but adds nothing about what a validation actually produces (errors thrown vs. a report), whether it consumes quota, or account/permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; every clause adds information. Appropriate size for the message.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no output schema, and only readOnly/openWorld annotations, a one-line description is thin. An agent still cannot tell what the tool returns on success or failure, which is the central question for a validation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It names only recipient, sender, and attachment concerns, leaving subject, bodyHtml, bodyText, replyAll, accountId, and replyToMessageId completely undocumented in both schema and prose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb ('Validate') plus the exact resources checked (recipients, sender, attachment limits) and explicitly negates sending mail, which cleanly separates it from the sibling send_email. It stops short of naming send_email as the alternative it pairs with, so differentiation is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Without sending mail' implies the pre-flight/dry-run context, so an agent can infer this runs before send_email. However, it never states when to call it versus just calling send_email or create_draft, and names no alternatives explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an email. Repeating a successful send with the same idempotencyKey and arguments returns the saved result instead of sending again. Reusing a key with different arguments, or after a failed or uncertain send, returns an error.
| Name | Required | Description | Default |
|---|---|---|---|
| cc | No | ||
| to | No | ||
| bcc | No | ||
| from | No | ||
| draftId | No | ||
| subject | No | ||
| bodyHtml | No | ||
| bodyText | No | ||
| replyAll | No | ||
| accountId | No | ||
| attachments | No | ||
| idempotencyKey | Yes | ||
| replyToMessageId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint, destructiveHint, and openWorldHint, but the description goes well beyond those booleans by spelling out the exact replay contract: same key + same args returns the saved result, while key reuse with different args or after a failed/uncertain send errors. That is precisely the nuance a boolean cannot convey. It still omits that a delivered email is irreversible and any account/permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, zero filler, purpose front-loaded followed by the failure/replay conditions that matter most for a caller. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter send tool with no output schema, the description covers the highest-risk aspect (idempotent retry behavior) but leaves the body of the parameter space unexplained — particularly how draftId relates to to/subject/body, and attachment encoding. Adequate for the risky part, thin overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 13 parameters, so the description must carry the semantic load, yet it only explains idempotencyKey (the required one) and says nothing about to/cc/bcc/from/subject/body variants/attachments/draftId/replyToMessageId/accountId/replyAll. The one explanation it does give is genuinely behavioral, but 12 params remain undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Send an email'), which is unambiguous on its own. However, it never distinguishes itself from the obvious sibling preview_send or explains the relationship to create_draft/update_draft, so the agent must infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not guidance, and no routing to alternatives such as preview_send (dry-run before sending) or create_draft. The description covers retry semantics but tells the agent nothing about when this tool is the right choice versus its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing mailbox draft.
| Name | Required | Description | Default |
|---|---|---|---|
| cc | No | ||
| to | No | ||
| bcc | No | ||
| from | No | ||
| draftId | Yes | ||
| subject | No | ||
| bodyHtml | No | ||
| bodyText | No | ||
| replyAll | No | ||
| accountId | No | ||
| attachments | No | ||
| replyToMessageId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, destructive, non-idempotent, open-world behavior, so the baseline bar is lower — but the description adds nothing beyond them. It does not say what gets overwritten (whole draft vs. only supplied fields), whether omitted fields are cleared, or what permissions/account context are required for a destructive mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single short sentence with no filler, so it is concise and front-loaded. However, brevity here is emptiness rather than efficiency — the sentence carries no actionable content for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter destructive mutation with no output schema and no parameter documentation, the description is far too thin. An agent cannot determine which fields are patchable, what happens to unmentioned fields, or how attachments and reply metadata are handled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 12 parameters at 0% description coverage, including non-obvious ones like replyAll, replyToMessageId, and the attachments sub-object, and the description never mentions a single field or the update/patch semantics. With no output schema and no enum guidance either, the description does nothing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the name and title almost verbatim ("update_draft" / "Update draft" → "Update an existing mailbox draft") without adding scope or distinguishing it from create_draft, delete_draft, or get_draft. It names a verb and resource, but a reader learns nothing not already in the identifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus its siblings, no mention of prerequisites (does the draft have to exist? must it be unsent?), and no indication of how it differs from send_email or create_draft. The only implied usage is the tautological 'existing draft'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
download_attachment1 field changedInput schema / properties / inlineAdded value: +{
+ "type": "boolean"
+}create_draftdelete_draftdownload_attachmentget_delivery_operationget_draftget_emailget_threadlist_accountslist_emailslist_folderslist_labelslist_send_asmodify_emailspreview_sendsend_emailupdate_draft
Add one secure layer between your agents and this server.