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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does state the core side effect: the browser is closed and the session is cleaned up. However, it does not mention whether the action is irreversible, whether unsaved state is lost, or what consequences 'session cleanup' entails.

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 one short, front-loaded Korean sentence. It conveys the action and its purpose without filler or redundancy, which is ideal for a simple zero-parameter tool.

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 simplicity of the tool—no params, no output schema, no annotations—the description covers the essential information needed to invoke it. It could be more complete by addressing when to close versus other terminal actions, but for a basic close operation it is reasonably sufficient.

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 confirms this, so the description is not required to explain parameters. The baseline of 4 applies because there is no parameter burden to compensate for.

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—'close the browser and clean up the session'—rather than merely restating the tool name. This clearly distinguishes it from siblings like open, wait, status, and screenshot.

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 no guidance on when to use this tool versus alternatives such as 'done' or 'status'. It does not mention contexts, prerequisites, or exclusions, so an agent must infer usage from the name and action alone.

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?

Since no annotations are provided, the description carries full responsibility for disclosing behavior. It does so by stating that the tool mutates state (marks the transmitted batch as processed) and triggers an overlay with summary and highlighting. It does not discuss reversibility or error cases, but the key side effects are clearly exposed.

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 three sentences, purpose first, then effects, then mandatory usage. It is economical and front-loaded. The middle sentence is slightly jargon-dense ('갱신 전략', '오버레이') but still each sentence contributes needed 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 simple signalling tool with three parameters and no output schema, the description covers the trigger condition, side effects, and parameter roles. It leaves the exact meaning of 'update strategy' and 'batch' somewhat undefined, but an agent can reasonably infer when and why to invoke it.

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 compensate. It explains that 'summary' is displayed in the overlay and 'selectors' determine which elements to highlight. However, 'changedFiles' is only indirectly referenced via '전송된 묶음' (sent batch), which is vague. Partial compensation for the lack of schema docs.

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 '수정 완료 신호' (modification completion signal), immediately stating what the tool does. It then details the specific behaviors: executing an update strategy, displaying a summary, highlighting selector-matched elements, and marking a transmitted batch as processed. This clearly separates it from the observational and navigational sibling tools (status, wait, screenshot, open, close).

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 final sentence '매 수정 후 반드시 호출' explicitly instructs when to call the tool: after every modification. This is strong usage context, but the description does not mention when not to use it or name alternative tools, so it stops short of a 5.

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 disclose meaningful side effects: enabling a feedback overlay, launching the browser when absent, and restoring saved drafts/history. However, it leaves unclear whether existing state is overwritten, whether this is destructive, and what the recovery actually entails.

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, each adding a distinct fact: opening the URL, overlay behavior, and recovery. The main action is front-loaded, though the final sentence is vague and could be more precise without losing conciseness.

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 low-complexity tool this describes the core behavior, but it omits workflow context (relationship to done/screenshot), the strategy parameter in the prose, and any return/error behavior. With no output schema or annotations, those omissions are noticeable but not fatal.

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%; the strategy parameter is documented in the schema but the tool description adds nothing about it. The description's mention of 'URL' merely restates the required parameter and does not enrich the uri format already defined in 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 action ('open URL in a dedicated browser') and adds distinguishing details: it turns on a feedback overlay, launches the browser if missing, and recovers saved drafts/history. This separates it from siblings like screenshot or close, though it does not explicitly name an alternative.

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 guidance on when to choose this tool over siblings such as screenshot or wait. The only conditional statement, 'if no browser, launch it', is a behavioral detail rather than usage guidance, and no exclusions or alternatives are mentioned.

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 burden and reveals meaningful behavior: output is a saved file path, the image is not attached to the conversation, and the file format is PNG. It does not cover details like file location or overwriting, but the most decision-relevant behaviors are disclosed.

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 no filler: the first states the core action and return value, the second states a crucial limitation for the agent. 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?

For a simple tool with one optional parameter covered by the schema, the description plus schema is complete: it states what is captured, the file format, the return value, and that the image will not be visible in conversation. No output schema is needed to understand what the tool 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 100% and the schema already explains the selector parameter clearly (crop around the first matching element, viewport if omitted). The description adds no parameter-level information, so the schema-heavy 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 uses a specific verb-resource pair: saves the current screen to a PNG file and returns the path. It is clear and unambiguous against the sibling tools, though it does not explicitly name an alternative or contrast with another action.

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 intended use is implied by the name and the action ('current screen'), but there is no explicit guidance on when to prefer screenshot over open/wait/status/done/close or any exclusions. An agent can infer the primary case but is given no context about alternatives or prerequisites.

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 burden. It does disclose the core visible effect — showing a status line in the overlay — and gives an example. However, it does not explain whether the status is transient, overwrites prior text, or is cleared by tools like done.

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 sentence that is front-loaded with the primary purpose, and the example adds clarity without unnecessary bulk. Every element 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?

For a simple one-parameter tool, the description is near-adequate. However, without annotations or lifecycle details, an agent does not know whether the status persists, gets replaced, or should be cleared after task completion.

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 partially compensates by clarifying that the text is the agent status line content and by providing an example. It does not explain formatting expectations or whether the text should be concise, leaving the agent to infer from maxLength and the example.

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 and resource: it displays one line of agent status on the overlay status bar, with a concrete example ('수정 중: Button.tsx'). This distinguishes it from the sibling tools like open, wait, or screenshot, though it does not explicitly 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 provides no explicit guidance about when to use this tool versus alternatives, or when not to use it. The example implies it is for showing progress-related status, but the agent is left to infer usage context.

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 behavioral disclosure burden. It reveals blocking behavior, the pending-status loop, and the meaning of payload.batches[].note. It omits timeout/error behavior, but the disclosed traits are substantive and useful.

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 sentences, each earning its place: the main action is front-loaded, the polling loop follows, and the payload interpretation rule is given last. There is no filler or redundant restatement.

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 core loop and payload interpretation are covered, but there is no output schema and the description does not explain non-pending statuses, timeout outcomes, or how this tool relates to siblings like status and close. Given the timeoutSec parameter, this is a meaningful 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 only parameter, timeoutSec, is already fully described in the schema with minimum, maximum, and default behavior. The description does not add parameter-specific detail, 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 exactly what the tool does: it waits until the user presses Send in the overlay. The additional pending-status instruction clarifies that this is a blocking wait-for-user-action tool, not a general status-checking tool.

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 clear usage context: call wait to block for the user's Send action, and call wait again if the result status is 'pending'. It does not explicitly mention alternative tools or when-not-to-use conditions, so it stops short of a 5.

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