Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds essential behavioral context beyond the annotations: it opens Google sign-in in the user's browser, requires the user to authenticate, and stores the refresh token only on this computer. This meaningfully complements the openWorldHint and idempotentHint annotations without contradicting them.

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 compact sentences, with the action front-loaded and the noteworthy security/storage behavior immediately following. No filler or restatement of schema content.

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 2-parameter tool with a browser-based auth flow and no output schema, the description covers the main agent-relevant facts: what gets connected, how user interaction works, and where credentials are stored. It could optionally describe the post-auth return value, but the description is sufficient for correct invocation.

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 input schema already documents both 'alias' and 'replace' clearly, including the confirmation-only rule for replace. The description does not add parameter-level detail beyond the schema, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Connect'), a specific resource ('a Gmail or Google Workspace account'), and the mechanism (Google sign-in, alias storage). This makes the tool clearly distinct from siblings like list_mailboxes, read_email, and disconnect_mailbox.

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 conveys the exact setting for use: connecting a new Gmail/Google Workspace account under an alias. It implies when this tool is appropriate versus listing or reading mailboxes, and adds practical context (browser sign-in), though it does not explicitly name alternatives or exclusion conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructive and idempotent behavior. The description adds valuable context by specifying exactly what is destroyed (alias plus encrypted OAuth token) and what is preserved (the Google Account grant), which goes beyond the annotations without contradicting them.

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 compact sentences, both informative, with the core action front-loaded and the critical scope limitation in the second sentence. No filler or redundant repetition of schema 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?

Given a single simple parameter, no output schema, and strong annotations, the description covers the essential behavior and constraints. It could mention side effects on other local data or error behavior, but for this tool's complexity, the provided context is sufficient.

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 already fully documents the only parameter 'alias', including the 'with or without @' detail, so the description does not need to add parameter semantics. This is the appropriate baseline because schema coverage is 100%.

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 clearly states a specific action: 'Delete one mailbox alias and its encrypted OAuth token from this computer.' It names the resource and the scope, making it easy for an agent to distinguish from list/search/read siblings.

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 behavior is described clearly, and the statement 'This does not revoke the grant in the Google Account' implies a key usage boundary, but there is no explicit guidance on when to choose this tool over siblings or when to use an alternative. The context can be inferred but is not directly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds minimal behavioral context beyond the annotations. The readOnlyHint, openWorldHint, and idempotentHint already convey that this is a safe, read-only listing operation. The phrase 'connected' adds a small amount of scope information, but no deeper behavior is 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 two short, focused sentences. It front-loads the operation and immediately follows with a practical use case. Every sentence earns its place with no redundancy.

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, idempotent listing tool, the description is complete. An agent knows what the tool does, when to invoke it, and has no additional parameters or prerequisites to worry about.

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 has zero params, so schema coverage is effectively 100% and there is nothing for the description to compensate for. The baseline of 4 applies because there are no parameter semantics to clarify.

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 uses a specific verb and resource: 'List connected Gmail mailbox aliases.' It clearly identifies the operation as listing available aliases, which distinguishes it from sibling tools like read_email, connect_mailbox, or search_mailboxes.

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 explicitly states when to use this tool: 'when an alias is unknown or the user asks which mailboxes are available.' This gives clear context, though it does not name alternative tools or explicitly 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, openWorld and idempotent, so the safety profile is well covered. The description adds a small practical constraint ('always pass both') and the mailbox-search provenance, but does not disclose additional behavioral details such as return format or possible errors. This meets but does not exceed the bar.

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, no padding, and the most important constraint ('Always preserve both...') is placed after the core action. 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 simple, read-only two-parameter tool with strong annotations and a clear sibling context, the description is nearly complete. It could have stated what the read operation actually returns, but the low complexity and explicitly safe behavior make this a minor gap.

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 coverage is 100%, so the schema already fully documents both parameters. The description essentially reiterates the schema's assertions ('source mailbox alias', 'message ID returned by a search') without adding new detail, so a baseline of 3 is appropriate.

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 ('Read a Gmail message') and immediately scopes it to 'returned by a mailbox search,' which distinguishes it from the mailbox-management and search sibling tools. This is clear, direct, and actionable.

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?

It clearly indicates that the tool operates on search results and requires both the source mailbox alias and message ID. It does not explicitly mention alternatives or say when not to use it, but the context and sibling list make the usage scenario clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already provide key behavioral context (read-only, open-world, idempotent). The description adds meaningful detail beyond annotations by pointing out that all mailboxes are searched in parallel, which affects concurrency expectations, and clarifies that Gmail syntax is used.

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 one sentence that thoroughly covers scope, target resources, and behavior with no wasted words. It front-loads the key action for 'search every mailboxes in parallel' and ends with the syntax detail.

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 tool with two optional parameters, strong annotations, and a well-known search semantics, this description is complete enough for an agent to invoke correctly. It could be slightly more complete by mentioning that results are aggregated across mailboxes or noting a limit caveat, but those are minor and not critical.

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 coverage is 50%; only 'query' gets a description, while 'max_results_per_mailbox' is unnamed but self-explanatory. The description adds 'normal Gmail search syntax,' which is a decent hint about query semantics but adds no new meaning for the max_results parameter beyond what the name suggests.

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 clearly states the action is a search across all connected Gmail/Google Workspace mailboxes, with parallel execution. This distinguishes it from siblings like search_mailboxes, which would target a narrower scope. The specificity of 'every connected mailbox' makes the tool's purpose unmistakable.

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 implies the use case (searching all mailboxes at once) but does not explicitly state when to prefer this over alternatives like search_mailboxes or list_mailboxes. It lacks clear exclusion criteria or mention of sibling tools for comparison.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds useful behavior beyond the read/readonly annotations: searches run in parallel, aliases must be normalized to omit the @ prefix, and query semantics follow Gmail search syntax. Since the annotations already cover read-only and idempotence, this is good additional behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, all useful, with the most important scoping and usage guidance front-loaded. No filler or repetition of schema fields.

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?

The description is sufficient for a read-only search tool with clear input semantics and schema bounds. It could arguably mention what the results look like or explicitly redirect to search_all_mailboxes for the all-mailboxes case, but it is otherwise complete for correct invocation.

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 description adds meaningful alias-construction semantics for the mailboxes parameter (strip the @ prefix from chat mentions), which goes beyond the schema text. It also clarifies that query uses normal Gmail syntax. The max_results_per_mailbox parameter still lacks semantic description, but its min/max/default bounds aid the agent.

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 clearly identifies the action: searching multiple named Gmail or Google Workspace mailboxes in parallel. It distinguishes this from searching all mailboxes by emphasizing named/selected mailboxes, and the title reinforces the scope.

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?

It gives concrete usage guidance: convert @aliases into the mailboxes array without the @ prefix, and use normal Gmail syntax for the query. It does not explicitly mention when to prefer search_alld_ailboxes over this tool, but the selected-vs-all distinction is clear enough that an agent can infer the correct sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.