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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds that it only returns the email address and configuration status, never the authorization code, which is a useful disclosure about output sensitivity.

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 that states the core action, the returned data, and an explicit exclusion without any filler. Every clause 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?

Given the simple read-only nature, the empty input schema, and the rich annotations, the description covers what the tool does and what data it returns. It could optionally clarify what 'configuration status' means (e.g., configured/not configured), but it is adequate.

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 parameters, so the baseline for parameter semantics is 4. There are no parameter details to document, and the description appropriately does not discuss inputs.

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 tool checks whether the current connection is configured, using a specific verb '检查' (check) and resource '连接配置' (connection configuration). It distinguishes from sibling tools like qq_mail_read and qq_mail_search, which perform mail operations rather than status checks.

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 explicit when-to-use or when-not-to-use guidance is provided, nor are any alternatives mentioned. The description only states what the tool does, not when to invoke it versus the sibling mail tools.

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, idempotentHint and destructiveHint, but the description adds a genuinely useful behavioral detail beyond them: it will not mark messages as read, which is the key side-effect concern for a mail listing tool. It omits pagination and rate-limit behavior, keeping it below a 5.

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 dense sentence that front-loads the read-only guarantee and then the return value; every clause carries information and there is no 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?

With no output schema, the description correctly compensates by naming the returned fields (mailbox and uid) and their downstream use. The main remaining gap is any statement about result limits or paging, though limit is covered by the schema.

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 100%, so both limit and mailbox are already documented in the schema. The description adds no syntax, format or defaulting information beyond that, so the baseline 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 and resource with scope: '以只读方式列出 QQ 邮箱的未读邮件摘要' (list unread QQ mail summaries read-only). The 'unread' qualifier naturally separates it from qq_mail_read and qq_mail_search, though no sibling is named explicitly, so it falls just short of the top mark.

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 a clear usage context and a workflow pointer: the returned mailbox and uid '可用于读取指定邮件', implicitly routing the agent to qq_mail_read. It does not, however, state when to prefer qq_mail_search or any exclusions, so it stops at clear context without explicit routing rules.

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 this is a closed-world, read-only, idempotent, non-destructive call, so the bar is low. The description adds a genuine boundary beyond them: it discloses that no authorization code is returned, which prevents an agent from treating this as a credential-fetching 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?

Two short sentences, front-loaded with the return subject and followed by the intent and the exclusion. No filler, and the negative constraint is placed where it is most likely to be read.

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 burden of signaling what comes back, and it does so at a high level ('identity', explicitly not the auth code). A parameterless read tool with full annotation coverage does not need more, though the exact identity fields remain unspecified.

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 is nothing for the description to disambiguate and the schema is fully self-sufficient. Baseline of 4 applies for a parameterless tool.

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: it returns the QQ Mail identity bound to the current OAuth connection, and adds the intent of distinguishing between multiple mailbox connections. It is clear but never names the nearest sibling (qq_mail_connection_status), so an agent must infer the boundary itself.

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 clause '帮助区分多个邮箱连接' implies the usage scenario (multiple connections present, identity disambiguation needed) but gives no explicit when-not-to-use rule and names no alternative among qq_mail_connection_status or the read/search siblings. Usage is inferable but not 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 annotations already declare the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description adds the genuinely useful behavioral fact that it will not download attachments or mark the message as read — a common ambiguity in mail clients. It stops short of describing error or pagination behavior, but the added context is real.

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 sentence that leads with the action, then the data source, then the non-effects. No filler and nothing repeated from 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 correctly summarizes the return value (body plus attachment metadata) and the absence of side effects. A 2-parameter read tool with annotations is well covered, missing only failure/empty-result behavior.

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 only 50%: mailbox has a default but no description, and uid is already documented as needing to come from list/search results. The description compensates partly by asserting both mailbox and uid originate from list or search results, but adds no format, default, or casing details beyond the schema.

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 — reading one QQ mail's body and attachment metadata — and scopes it to a single message, which cleanly separates it from qq_mail_list_unread and qq_mail_search that return collections. An agent can pick this tool over its siblings 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?

It states that mailbox and uid must come from a list or search result, which effectively tells the agent this is a follow-up call to qq_mail_list_unread or qq_mail_search. That is clear usage context, though there is no explicit statement of when not to use it or what happens if a stale uid is supplied.

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, idempotentHint and destructiveHint=false, so '不改变邮件状态' largely restates structured data rather than adding new behavior. The one genuinely additive detail is the '当前已授权' scoping, which hints at the auth boundary; return format and pagination behavior remain undisclosed.

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 the verb and resource first, followed by scope dimensions and a safety clause. No filler, nothing buried.

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 8-parameter search tool with no output schema, the description is workable because annotations cover the safety profile and the schema covers types. However, it does not address result ordering, the limit default/cap, or the INBOX default, leaving real gaps an agent would want when composing a query.

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 75%, so the schema already documents most parameters including date patterns and unread semantics. The description mirrors the filter list but adds no syntax, default-value, or interplay detail, and omits mailbox and limit entirely — baseline 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?

States a specific verb (搜索) and resource (QQ 邮件) with the searchable dimensions enumerated (关键词、发件人、主题、日期、未读状态). It clearly differentiates a filtered search from qq_mail_read, but never names siblings like qq_mail_list_unread, which covers overlapping unread filtering.

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 enumeration of filter dimensions, but there is no explicit when-to-use or when-not-to-use guidance, and no mention of qq_mail_list_unread as the narrower alternative for unread-only queries. An agent must infer routing from the sibling names.

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