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

With no annotations, the description carries the full burden and does substantial work: it discloses DNS re-resolution per call, refusal of unconfirmed origins, password fields, and challenge widgets, and that fill/press require a value. It stops short of stating auth requirements or what the response 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?

Four short sentences with the core action front-loaded, and the value-requirement clause placed after. 'Re-resolves DNS on every call' is slightly tangential but earns its place as a behavioral hint; otherwise there is little waste.

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 4-param mutation tool with no annotations and no output schema, the description covers behavioral constraints and refusals well. It lacks return-value and authentication details, but given the sibling family (auth_login, auth_status, auth_read) the missing pieces are modest.

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 all four parameters, including 'value' required for fill/press and selector details. The description only echoes the 'fill and press require value' constraint, adding no syntax or format meaning beyond the schema; 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 set (click, fill, press) acting on a specific resource (this site's current page), which is concrete. It doesn't explicitly distinguish itself from siblings like auth_login, auth_open, or auth_read, but the single-action framing is clear enough for an agent to select it.

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 some negative guidance (does not solve CAPTCHA or 2FA, refuses unconfirmed origins/password fields/challenge widgets), which implies when-not. However it never names when to prefer a sibling (e.g., auth_login for authenticating, auth_read for reading) or states prerequisites, so usage is only implied.

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?

With no annotations, the description carries the full burden and does reasonably well: it discloses the 10-minute signal window, the refusal condition if the signal is missing, the constraint that workOrigin must belong to the same signal, and explicitly that it 'does not read cookies.' It doesn't say what is returned or whether the recorded origins are reversible.

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 dense sentences, front-loaded with the core action and prerequisite, with no filler. Some phrasing is awkward (the embedded Korean label, 'terminal confirm command'), but every sentence carries a distinct constraint.

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 state-recording tool with no annotations and no output schema, the description covers the prerequisite, the failure mode, the optional-param constraint, and one explicit non-behavior ('does not read cookies'). Return values aren't described, but that is a minor omission given the tool's narrow scope.

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 baseline is 3, but the description adds genuine semantics beyond the schema: workOrigin must be part of the same human allow signal, tying an optional param to a runtime precondition the schema does not state.

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+resource: 'Record origins for one site' gated on a human allow signal. Clear enough to distinguish from read-oriented siblings, but it never names or contrasts auth_login/auth_open/auth_read/auth_act/auth_status, so differentiation is inferred rather than explicit.

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 (a human allow signal within the last 10 minutes) and a sequencing rule ('use this after the terminal confirm command'), and notes the 이 사이트 허용 button path already confirms origins. It does not explicitly route against specific sibling tools, so it falls short of a full when/when-not with alternatives.

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?

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.

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

With no annotations, the description carries the full burden and does so well: it discloses DNS re-resolution with address pinning, fail-closed behavior when the connected address falls outside the checked set, the human_action_required return path with suppressed page text on login/challenge pages or unconfirmed final origins, and blocking of subresource requests to link-local/metadata hosts. These are exactly the non-obvious safety traits an agent needs.

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 compact sentences, each carrying distinct information, with the core action and the origin precondition front-loaded. Density is high and there is little waste, though the middle sentences pack multiple clauses that slightly reduce scannability.

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 security-sensitive tool with no annotations and no output schema, the description covers preconditions, failure modes, and the human_action_required return path well. It leaves the success return value implied rather than stated and does not explain how the opened page relates to subsequent auth_read/auth_act calls, 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 both parameters (site, url) are already fully documented with formats and constraints. The description's phrase 'confirmed origin' loosely constrains the url parameter but adds no syntax or format detail beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 concrete verb and resource: 'Open a URL in that site's Chrome profile.' That is unambiguous about the action and the per-site Chrome profile scope. It does not explicitly contrast itself with siblings like auth_read or auth_act, so an agent must infer when opening differs from reading or acting.

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 a hard precondition: the origin must already be human-confirmed (login origin or work origin), which tells the agent this tool must follow auth_confirm/auth_login rather than being a first step. It gives clear context but names no alternative sibling or exclusion, so routing between auth_open and auth_read/auth_act is not spelled out.

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?

Goes well beyond the readOnlyHint annotation: DNS is re-resolved on every call, unconfirmed origins are refused, long text is truncated, and cookies/storage are never returned. These are exactly the operational facts an agent needs before invoking it.

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?

Five terse sentences, each carrying a distinct constraint (mode, DNS, origin refusal, truncation, non-return of secrets). The primary purpose is front-loaded and nothing is 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 partially covers return behavior (visible text only, truncated, no cookies/storage). The main remaining gap is what the response looks like structurally and how truncation is signaled, but the essential call-correctness 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 coverage is 100%, so all three parameters are already documented, including that url must be on a confirmed origin. The description restates the confirmed-origin constraint for url but adds nothing about selector, so it is on par with the schema rather than additive.

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 ('Read visible text from this site's current page') plus the conditional navigation mode when url is set. This is clearly distinguishable from auth_open, auth_act, and auth_status among the 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?

Explains the two modes of use (read current page vs. navigate-then-read when url is set) and the gating condition (origin must be human-confirmed). It does not explicitly contrast with auth_open/auth_act for navigation or reading after actions, so an agent must infer which sibling to prefer.

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?

With only readOnlyHint=true in annotations, the description adds real value: it explains that needs_login means the last open saw a login page, that age makes a stale 'ok' visible, and explicitly that no cookies, tokens, or URL query secrets are returned. That security/return-content disclosure goes well beyond the annotation, though it says nothing about refresh/polling cost or freshness guarantees.

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 paragraph, front-loaded with the output shape before the semantic notes. Every clause carries information (field list, needs_login meaning, age rationale, no-secrets guarantee), though the field enumeration is somewhat list-heavy.

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 carries the return-format burden and does so thoroughly, and readOnlyHint covers the safety profile. It is complete enough to call correctly, with the only gap being guidance on when to prefer this over the sibling auth_* tools.

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% and the single optional 'site' parameter is fully documented in the schema ('Omit to list every site'). The description adds no further syntax or format detail for the parameter, so the 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 conveys that this is a per-site auth status report by enumerating the fields returned ('site id, confirmed login and work origins, last used time, last confirmed time, session age, and session ok or needs_login'). It is clear what the resource is, but it is framed as an output listing rather than a verb+resource statement and never contrasts itself with siblings like auth_read or auth_confirm.

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 statement of when to use this tool versus the other auth_* tools (auth_login, auth_confirm, auth_open, auth_read, auth_act). The only scoping hint is implicit in the site listing behavior, which the schema already documents. No exclusions or preconditions are given.

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