截取 IDE 或模拟器画面

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

无任何 annotations，描述承担全部行为披露责任。它确实补充了有价值的机制信息：IDE 走 Windows 原生拷贝（隐含平台限制）、模拟器走 CDP 截图、projectPath 用于多实例绑定。但未说明输出行为（返回值是什么、是否通过 outputPath 落盘、timeoutMs 的作用）以及失败情形（IDE 未打开、CDP 连接失败时怎么办），透明性只做了一半。

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?

两句话完成全部信息传递：第一句按目标任务分派机制，第二句补充多开场景的参数技巧。机制差异前置、绑定细节后置，信息密度高且无任何冗余，每一句都有独立价值。

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?

工具中等复杂（4 参数、两种截图路径），而上下文信号很弱（无 annotations、无输出 schema、参数覆盖 0%、无必填参数）。描述却遗漏了调用契约的核心：调用后返回什么、不传 outputPath 时截图如何获取、空参数调用会得到什么结果。代理能正确选择该工具，但无法预测其输出，这是一个关键缺口。

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 描述覆盖率为 0%，描述必须补偿参数语义。它实际做到了对两个参数的补充：target 的两个枚举值对应两种截图机制，projectPath 解释了多 IDE 绑定行为。但 timeoutMs 和 outputPath 在描述中完全没有语义说明，outputPath 的作用只能靠参数名猜测，属于部分补偿而非充分补偿。

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?

描述明确说明这是截图工具，且细分为两种目标：IDE 全窗和模拟器画面，并分别给出具体机制（Windows 原生窗口拷贝 vs. MiniApp Webview CDP 截图）。动词+资源+机制齐全，能与全部 16 个兄弟工具（如 douyin_preview、douyin_read_console_errors）清晰区分，没有任何职责重叠。

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?

描述给出了明确的使用场景：需要截取 IDE 窗口或模拟器画面时使用，并说明了多开 IDE 时传 projectPath 的绑定用法。但没有命名任何替代工具或排除条件，也没有说明与 douyin_preview 等在预览/截图职责上的边界，when-not-to-use 完全缺失。

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