auth_login

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose key behaviors: opens a visible window (not headless), returns immediately (non-blocking), does not type credentials, does not return the confirmation code. However, it doesn't state what the return value is, whether the window persists, what happens on repeated calls for the same site, or any permissions/preconditions. It covers more than most, but leaves meaningful gaps for a mutation-style tool with no annotation coverage.

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 first sentence is front-loaded and clear, but the reference to a local tab and the Korean button label ('이 사이트 허용') is opaque without context and reads as implementation detail rather than agent-relevant guidance. The final sentence packs useful negatives but the middle is less 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 tool with no annotations and no output schema, the description should clarify return values and flow position. It states it returns immediately and does not return the confirmation code, but doesn't say what it does return, nor how it relates to the sibling confirmation/status tools. Adequate for a minimal flow step but incomplete for a multi-sibling login pipeline.

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 the url and site parameters are fully documented in the schema, including the site id format and per-site Chrome profile behavior. The description adds no format, constraint, or semantic detail beyond what the schema already states, 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?

States a specific action (open a visible Chrome window) for a specific resource (one site id) with a human-in-the-loop purpose. It distinguishes from siblings by clarifying what it does NOT do (does not type credentials or return the confirmation code), which hints at the division of labor with auth_confirm/auth_act. The detail about the local tab listing origins and the 이 사이트 허용 button is somewhat idiosyncratic and could confuse without sibling context, 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?

The description implies usage (this is the first step in a login flow, after which a human acts and a confirmation step presumably follows), but it never explicitly says when to call this versus auth_open, auth_confirm, or auth_act. The 'Returns immediately' note hints that it's non-blocking, which is useful, but the routing among siblings is left to inference.

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