entry_screenshot

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

No annotations are provided, so the description carries the full disclosure burden. It does well to disclose a non-obvious side effect: when save_as is given, a PNG is written to 작업폴더/screenshots. However, it says nothing about what the tool returns (a screenshot payload or a path), whether capture may fail when the app is not running, or whether an existing file is overwritten.

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 definition is one dense, front-loaded sentence with the purpose first, followed by the option meanings, and then the write side effect. Nothing is wasted, though the telegraphic style and Korean-only phrasing could slow a non-Korean agent slightly.

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 two-parameter, no-required-argument tool with no annotations and no output schema, the definition covers both parameters. It is silent, however, on the return value and on the failure conditions, which matter for an agent that must decide whether to save to disk or consume the image inline.

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 supply the meaning, and it largely does. It glosses both enum values of target with concrete visual scopes and explains that save_as triggers PNG persistence in a specific directory. Only the filename format and overwrite behavior for save_as remain unexplained.

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 starts with a clear verb and resource, "화면 캡처" (screen capture), and immediately separates the two capture scopes, stage and window. It does not name any sibling tool, for example entry_preview_assets, or explain why one would choose this capture instead; however, the core purpose is unmistakable.

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 implicitly guides when each mode should be used: stage is for the execution screen only, while window includes the block editor. It never says when to reach for this tool rather than the many sibling asset, preview, or runtime-state tools, and it gives no prerequisites, so the agent must infer the usage context.

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