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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds one genuine behavioral note — that Gmail verifies the authenticated email address — but says nothing about failure modes, error reporting, or what a successful check 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 with the core purpose front-loaded and no filler. The second sentence about Gmail's email verification is terse and slightly cryptic, but it carries real information rather than padding.

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 one-parameter read-only check with no output schema, the description covers the basic purpose and safety context. However, it omits what the check returns on success/failure and how the required account_id is sourced, which an agent needs to invoke it 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% and the sole parameter account_id is undocumented in both schema and description. The description does not explain the parameter's expected format or where to obtain it (e.g., from list_accounts), leaving the agent to guess.

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 action and resource: a read-only connectivity check on an account. It clearly distinguishes itself as a diagnostic rather than a data-fetching tool like list_accounts or read_message, though it does not explicitly name those 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?

Usage is only implied: the phrase 'connectivity check' suggests verifying an account is reachable, but the description never states when to prefer this over list_accounts or what precondition failure means. No alternatives or exclusions are named.

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 readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds meaningful scope context beyond that: it discloses that credentials and mail are not touched, which tells the agent no secrets are exposed by the 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?

Two short sentences, zero filler, with the primary purpose front-loaded and the scope caveat second. Nothing in the text is redundant with the schema or annotations.

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 parameterless, read-only listing tool with an output schema already describing the return shape, the description covers everything the agent needs: what is listed and what is deliberately not accessed.

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 the schema-baseline of 4 applies; there is nothing for the description to disambiguate. No parameter semantics are needed or missing.

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 ('List configured account IDs and permissions'), so the agent immediately knows what it returns. It does not explicitly name or route away from the closest sibling (check_account), so it stops short of full sibling differentiation.

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 only implied: the agent can infer this is the discovery step before calling account-specific tools like check_account, but no when-to-use or alternative is stated. The scope exclusion ('does not access credentials or mail') is the only guidance offered.

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 readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful scoping context (single account, dual IMAP/Gmail backends), but does not describe result shape, hierarchy, or whether labels and folders are returned differently.

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; the scope qualifier is stated immediately after the verb and resource.

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 one-parameter read-only listing tool with annotations covering safety and no output schema, the description is nearly sufficient. The remaining gap is what the listing returns (flat vs nested, label vs folder differences), which is minor but non-zero.

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 a single parameter with 0% schema description coverage, so the schema does not document account_id at all. The description partially compensates by clarifying the account must be explicitly selected rather than inferred, but it adds no format, source, or lookup detail.

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 (list) and resource (IMAP folders or Gmail labels) plus a clear scope (one explicitly selected account). It is distinguishable from siblings like list_accounts or search_messages, though it does not explicitly name or contrast with them.

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 or when-not-to-use guidance and no mention of alternatives. The phrase 'one explicitly selected account' hints that an account must already be chosen, but this is inferred rather than stated, and nothing routes the agent between this and list_accounts or search_messages.

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 destructiveHint=true and non-idempotent behavior; the description adds genuinely new context by disclosing the required 'allow_manage' local setting and the fact that the change is verified. It does not, however, explain what happens on a conflict or how the verification result is surfaced.

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 filler, with the core action and the prerequisite permission front-loaded in that order. Every clause carries 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 mutation tool the annotations cover the safety profile and the description covers the auth prerequisite, which is good. But with a 0%-coverage schema and no output schema, the description leaves the caller guessing about identifier semantics and what the promised verification returns.

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 four parameters. The phrase 'read/unread state' maps loosely to the boolean 'read' parameter but never says that the default true marks as read, and mailbox, account_id, and message_id receive no explanation at all despite being required or defaulted.

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: it changes read/unread state and verifies the result. This clearly separates it from read_message and search_messages, which retrieve rather than mutate state. It is not a tautology of the name, though the name 'mark_read' understates the bidirectional read/unread capability the description reveals.

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 word 'Explicitly' hints that this is for deliberate state changes rather than incidental ones, and the permission prerequisite is stated. However, no alternatives are named and there is no guidance on when the caller should use this versus simply reading a message or relying on implicit read marking.

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 declare openWorldHint and destructiveHint=false, but the description adds genuinely new operational facts: nothing is sent, the From field is locked to the account email, and the issued token expires in 10 minutes. That expiry and the From-locking constraint are not derivable from the structured fields and are useful for correct invocation.

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?

Front-loads the core fact ('Create a local preview; sends nothing') and each following sentence carries a distinct constraint. It is a bit dense and could be trimmed, but no sentence is pure filler.

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 six-parameter, zero-coverage mutation-adjacent tool with no output schema, the description leaves gaps: it hints a token is produced but never says so explicitly or how it feeds send_prepared, and several parameters go unexplained. It covers the reply path well but is incomplete for the tool as a whole.

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?

With 0% schema coverage the description must carry full parameter load, and it only partially does. It explains account_id (From is locked to its email), reply_to_message_id (the parent provider message_id), and subject (must match for replies), but says nothing about recipients, body, or the mailbox parameter.

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 local preview' — and immediately clarifies 'sends nothing', which distinguishes it from the sibling send_prepared that actually dispatches. An agent can tell the two apart without opening either schema.

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?

Gives clear workflow context ('Show the entire preview to the user before sending') and a conditional rule for replies (provide the parent provider message_id, subject must match). It never names send_prepared as the follow-up step, so the routing to the actual send tool is left implicit.

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 cover the safety profile (readOnly, non-destructive, openWorld), yet the description adds genuinely non-obvious behavior: reading does NOT set the Seen flag, content is never executed, bodies are truncated and must be checked, and attachment file download is unavailable in v0.1. These are exactly the traits an agent cannot infer from annotations or schema.

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 with no filler, and the highest-value constraints (no Seen mutation, no content execution, bounded bodies) are front-loaded. Nothing restates the tool name or annotations.

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 still conveys the return shape (MIME text, attachment metadata, a truncated flag) and the v0.1 capability limit. It leaves mailbox defaulting and max_chars interaction with truncation unstated, which is a minor but real gap for a four-parameter 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 coverage is 0%, so the description must compensate, and it does for the most error-prone parameter: message_id is opaque and must come from search and match its original account/mailbox, which constrains account_id and mailbox too. max_chars is only indirectly explained via 'bodies are bounded; check truncated', leaving some 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 specific verb (Read) and resource (MIME text and attachment metadata), and adds a discriminating scope clause ('without setting Seen') that separates it from mark_read. It does not name a sibling directly, but the scope statement makes the boundary inferable without opening any schema.

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?

Gives a concrete calling prerequisite: use the opaque message_id returned by search, in its original account/mailbox. That is clear context for correct invocation, but it never states when to prefer this over search_messages or mark_read, and gives no explicit exclusions beyond the attachment-download limitation.

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 cover the safety profile (readOnly, non-destructive, open-world), but the description adds substantive behavior: no read-state mutation, provider-specific date semantics (Gmail UTC vs IMAP server calendar days), the pagination invariant that filters/account/mailbox must stay identical across cursor calls (otherwise results are inconsistent), and a prompt-injection warning that content is untrusted. That is meaningful disclosure beyond the annotations, though throttling and result-shape behavior remain unstated.

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?

Front-loaded with the single most important distinction ('Search without marking read'), then dense telegraphic sentences that each carry a distinct constraint. Efficient overall, though the fragment style makes it slightly harder to scan than a structured list would be.

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 10-parameter search tool with 0% schema coverage and no output schema, the description covers the non-obvious parameters and a few real behavioral constraints, but omits matching semantics for the free-text/sender/subject filters and anything about result content or ordering. Adequate but with clear gaps an agent must fill by trial.

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 carry all parameter meaning, and it only partially does. It explains date format/timezone semantics for after/before, the mailbox-as-label-ID rule with the empty-string edge case, and the cursor contract, but leaves text, sender, subject, limit and unread undocumented — the agent must guess whether 'text' is body/substring and how 'sender'/'subject' match.

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 ('Search...messages') and immediately adds the distinguishing side-effect constraint 'without marking read', which separates it from mark_read and read_message. It is clear what the tool does, though it never names the sibling alternatives explicitly.

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 'without marking read' clause implies when to prefer this over mark_read/read_message, and 'Use next_cursor with identical filters/account/mailbox' gives concrete continuation guidance. However, there is no explicit when-to-use rule or statement of exclusions, so usage is inferred rather than 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?

Annotations already flag destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-redundant behavior: single-shot send with no automatic retry, the local-settings enablement gate, and the caveat that acceptance does not prove delivery. This is real added context 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?

Four short sentences, each carrying a distinct operational constraint, with the authorization precondition front-loaded. Nothing is padded or repeated.

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, non-idempotent send with annotation coverage but no output schema, the description covers the key risks: authorization, no-retry, enablement, and the delivery caveat. The remaining gap is parameter explanation, which is not covered anywhere else.

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?

Both parameters have 0% schema description coverage and the description never mentions account_id or confirmation_token by name. 'Only after user authorization' faintly hints at the purpose of confirmation_token, but neither parameter's format, provenance, or constraints are explained, so the description does not 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?

States a specific verb and resource ('Send the exact preview once'), and the phrase 'the exact preview' clearly positions it as the execution step for the prepare_send sibling. It stops short of naming prepare_send explicitly, so sibling 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?

Gives a clear precondition ('only after user authorization') and an explicit prohibition ('Never automatically retry failures'), plus an environmental requirement ('sending must be enabled in local account settings'). It does not name the alternative tool or the exact step that must precede it, but the when-to-use context is strong.

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