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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds meaningful context: it wipes only the login and preserves the extension install, and the schema's confirm parameter is described as a safety gate. This goes beyond the annotations and clarifies the destructive scope.

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 conveys the essential scope and limitation. Every word earns its place, and it avoids restating the title or schema details.

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 destructive annotation, the confirm parameter, and the output schema, the description is nearly complete. It could mention that the operation is irreversible or suggest verifying with line_status afterward, but the core safety and scope information is present.

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 the schema already documents both parameters well. The description doesn't add much beyond what the schema says, but the 'confirm' parameter's safety role is reinforced by the description's 'refuses safely' wording. 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?

The description states a specific verb ('Wipe') and resource ('LINE login'), and distinguishes itself from a broader uninstall by clarifying that the extension install stays. It is clear and concise, though it doesn't explicitly name a sibling tool for comparison.

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 a narrow use case (clearing only the login, not the install), which helps an agent decide when to use it. However, it doesn't explicitly state when not to use it or mention alternatives like probe_session or line_status for checking state before/after.

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 provide readOnlyHint, openWorldHint, and idempotentHint, covering safety and idempotency. The description adds valuable context beyond that: 'Side-effect free: no files written' reinforces read-only, and 'Only rows rendered on screen are visible (virtualized list)' discloses a critical limitation about what data is accessible. This enriches the agent's understanding of the tool's behavior.

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 concise sentences. The first sentence front-loads the primary action and the optional room behavior, while the second adds critical behavioral caveats. No unnecessary words or redundancy; 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?

The tool has 9 parameters but none required, and an output schema exists to define return values. Annotations cover read-only, idempotent, and open-world aspects. The description explains the core operation and the virtualization limitation, which is the key behavioral constraint. Combined with schema and annotations, the agent has enough information to call the tool correctly.

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 89%, so most parameters are already documented in the input schema. The description does not add additional meaning to parameters beyond what the schema provides; it only mentions `room` in passing. Since the schema carries the heavy lifting, a baseline score 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 action: 'Read latest messages, opening a room first when `room` is given.' This clearly identifies the verb (read) and resource (LINE messages), and the optional room-opening behavior. It distinguishes from siblings like search_messages (search) and unread_digest/unread_full (unread summaries) without needing to name 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?

The description implies usage for reading messages from the current view or a specified room, but it does not explicitly contrast with sibling tools or state when to prefer this over search_messages or unread_* tools. The context of sibling names suggests differentiation, but the description itself provides no explicit when-to-use guidance or exclusions.

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 openWorldHint, so the description's main job is to add operational detail. It does this by listing the 5 readiness steps checked and disclosing that failures return a `next` field with user guidance, which is genuinely useful beyond the structured metadata.

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 tight sentences: the first names the resource and steps, the second gives invocation priority and failure behavior. There is no filler or repetition of schema/annotation 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 tool with zero parameters and an output schema, the description supplies everything an agent needs: what is checked, when to call it, and what to do with a failed result. The annotations cover safety and idempotency, so nothing important 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?

There are no parameters, and the schema fully documents this with an empty properties object, so the baseline is 4. The description adds no parameter-level detail, but none is needed.

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 ('Check') and a concrete resource (the 5 readiness steps: Chrome, attach, extension, page, login). It clearly states what the tool does and is easy to distinguish from sibling tools like wait_login or clear_session.

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 explicitly tells the agent to 'Call this first when unsure the setup works', which gives a clear trigger condition. It does not enumerate when-not-to-use cases or alternatives, but the priority guidance is strong enough to route the agent correctly.

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 readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is established. The description adds value beyond annotations by specifying result contents and warning that index values shift when rooms reorder.

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 compact sentences with no fluff. The first states the purpose, and the second delivers a practically important stability warning without repeating schema or annotation 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?

With an output schema, fully described parameters, and annotations covering read-only/idempotent behavior, the description only needs to add operational context. It supplies the essential guidance: result contents, stable identifiers to pass to other tools, and reorder risk.

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%, with query and unread_only each having clear descriptions and defaults. The tool description adds no parameter-level detail, so the baseline 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 opens with 'List chat rooms with unread counts and last-message preview,' naming a specific verb, resource, and expected output fields. This clearly distinguishes it from message-level siblings like get_messages and search_messages.

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 statement of when to use list_rooms versus alternatives like unread_digest or unread_full. The second paragraph gives useful cross-tool guidance about preferring data-mid or name, but selection among sibling tools is still left to inference.

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 mark this as read-only and idempotent, and the description reinforces this with 'without changing anything.' It adds meaningful beyond-annotation context by disclosing the redacted return behavior: 'Returns key names with type and length only, never secrets.' This is valuable safety-relevant detail, though it doesn't cover potential rate limits or 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?

The description is compact and front-loaded: purpose first, usage next, return safety last. Every sentence earns its place, and there is no redundant or filler 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?

Given zero parameters, an output schema, and annotations covering safety, the description provides all essential context: what the tool checks, when to use it, and what the response will and will not contain. No critical information is missing for an agent to select and invoke it correctly.

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 and the schema fully reflects that with 100% coverage, so there are no parameter semantics for the description to clarify. The description correctly focuses on behavior and return values instead.

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 verb and resource: 'Check login state and redacted storage without changing anything.' It also signals its non-destructive role relative to clear_session. However, it does not explicitly differentiate itself from the sibling line_status, which likely also reports login state, so full sibling distinction is missing.

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 an explicit usage trigger: 'Call this before clear_session, or when login looks flaky.' This tells the agent when to invoke the tool, but it does not mention when not to use it or name alternatives such as line_status for status-only checks.

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?

Beyond the readOnly/openWorld/idempotent annotations, the description discloses important non-obvious behavior: it is sequential, roughly seconds per room, reports progress per room, returns error entries for unmatched refs, and a bad ref never fails the whole search. This is exactly the kind of behavioral context that helps an agent set expectations and interpret results.

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 compact and front-loaded: one sentence states the core purpose, and a short second paragraph carries the behavioral caveats. Every sentence adds value, with no filler or repetition 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?

Given the rich input schema, output schema, and annotations, the description covers the remaining operational essentials: scoping, performance, progress reporting, and partial-failure semantics. Nothing needed to invoke the tool correctly 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?

Schema description coverage is high (83%) and the parameter descriptions are already rich, including room ref types, date formats, and scroll behavior. The tool description itself adds little parameter-level meaning beyond reinforcing the 'per room' concept, so a 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?

The description opens with a specific verb+resource: 'Search a keyword inside the given rooms only.' It clearly defines the scope (given rooms only) and the result shape (only rooms with matches), which distinguishes it from message-retrieval siblings like get_messages and from any unscoped search.

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 main description states that search is restricted to the given rooms, and the rooms parameter explicitly says to 'Get candidates from list_rooms first' and that unscoped search is not offered. This gives solid context and a clear prerequisite, though it does not explicitly name alternative tools for when a different operation should be chosen.

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?

An already carry safe annotations (readOnlyHint, idempotentHint), so the description doesn't need to restate them. It adds useful behavioral context beyond annotations: the tool is designed to be a cheap, single-call digest that returns previews only. This distinguishes it from alternatives and hints at resource characteristics without contradicting any annotation.

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 concise sentences. The core purpose is front-loaded in the first line, and the second line adds routing guidance without any fluff. Every word 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 this is a zero-parameter tool with a full output schema and clear annotations, the description is mostly complete. It covers purpose, usage context, and cost tradeoff. It doesn't detail what constitutes a 'latest preview' or how rooms are sorted, but the output schema are available to an agent, so this is a minor gap rather than a blocking one.

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 zero parameters, there is no param information to provide, and the baseline for zero parameters is 4. The description doesn't need to elaborate on param semantics because there are none, and the schema fully covers this aspect at 100% coverage.

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 opens with a clear, specific verb+resource stamenent: 'Unread rooms with latest preview in one call.' It directly distinguishes itself from unread_full by noting that it returns only previews, not full message bodies, which eliminates ambiguity about what the tool does.

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 explicitly frames the tool as the 'Cheapest what is unread check' and instructs users to choose unread_full instead when they need full message bodies. This gives a clear when-to-use and when-not-to-use rule, naming the alternative and the condition that selects 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?

Beyond the readOnly/openWorld/idempotent annotations, it discloses that the tool opens each unread room sequentially, that cost scales with unread count, and that progress is reported per room. This is useful operational behavior an agent could not infer from the annotations alone.

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 with no filler; the core purpose is front-loaded and the cost/progress notes are each distinct. Minor duplication between 'one room at a time' and 'Opens each unread room' keeps it from a perfect score.

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 that an output schema exists and the parameter schema documents date and scroll well, the description supplies the key behavioral context an agent needs: per-room iteration, cost growth, and progress reporting. It is complete except for missing sibling-vs-alternative guidance, which is more of a usage-guidelines 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?

The description contains no parameter-level information; date, scroll, and limit_per_room are only documented in the schema. With schema coverage at 67%, limit_per_room is left to its name and constraints, and the tool description adds nothing to clarify it.

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 the resource ('unread rooms') and the payload ('message bodies') and adds the scoping qualifier 'one room at a time.' It implies retrieval, though it never uses an explicit verb like 'returns' or 'lists,' and it does not explicitly contrast with sibling unread_digest.

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 cost warning ('cost grows with unread count') gives an agent a reason to pause before using this tool, so some usage context is present. However, it never states when to choose this over unread_digest, get_messages, or other siblings, and doesn't give an exclusion condition.

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?

Beyond the annotations, the description and parameter schema disclose key behaviors: Chrome runs headless, a window pops only for QR scan, the user can log in via QR or email, and the tool settles briefly to prove headless reuse. It does not contradict the readOnlyHint, since the tool itself waits rather than performing a write.

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 concise sentence that names the action and the goal with no filler. The additional behavioral details are placed in the parameter schema where they belong, keeping the main description lean and front-loaded.

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 one-parameter wait tool with annotations and an output schema, the description covers the essential purpose and behavior. It does not mention timeout failure behavior or the case of an already-authenticated session, but those are minor gaps given the schema's timeout documentation.

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%, and the timeout_sec parameter has a thorough schema description including default, min, max, and behavioral context. The main description adds no additional parameter meaning, so the 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 clearly states the verb ('Open Chrome and wait') and the specific goal ('until the user finishes LINE login'). It is distinguishable from sibling tools like line_status or probe_session because it focuses on the interactive login wait, not on querying session state. It does not explicitly name siblings, so it falls just short of a 5.

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 clear context that this is the prerequisite login step: after login, later tools can call right away. It implies when to use it, but it does not state exclusions (e.g., 'skip if already logged in') or mention alternative session-check tools like probe_session.

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