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

The annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context beyond those annotations by promising a token-saving compressed image, which helps an agent reason about cost and output size. It does not fully describe how the image is returned, but the safety profile is already established.

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, front-loaded sentence that states the action, the object, and the key benefit. It contains no filler and does not redundantly repeat schema details.

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 and no parameter descriptions, the description leaves important gaps: how the compressed image is returned, where targetId comes from, and how to choose meaningful values for format, quality, and maxWidth. The annotations are strong, but they do not fill these invocation-semantics gaps.

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%, and the description does not compensate by explaining any parameter semantics. It does not clarify that targetId identifies the target device, nor how format, quality, and maxWidth interact with the token-saving goal.

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 clearly states the action (capture a real-device screen) and the distinctive output (a compressed image that saves tokens). This differentiates it from sibling tools like mobile_get_logs, mobile_interact, and mobile_read_evidence, which cover different resources or actions.

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: use this when a mobile screenshot is needed. However, it gives no explicit guidance about when not to use it or which sibling tools to prefer for related tasks such as reading evidence or retrieving logs.

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?

Annotations already establish the operation as read-only, idempotent, and non-destructive. The description adds useful behavioral context by revealing that the tool invokes ADB, go-ios, and official HDC, and that targeting a single device is optional. No contradiction with annotations exists.

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 compact sentence with no filler. It front-loads the core purpose (running platform-specific diagnostics) and then states the optional targeting behavior. Every word contributes meaning.

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-optional-parameter, read-only diagnostic tool with strong annotations, the description is largely sufficient. It could be more complete by mentioning the expected output or how targetId relates to mobile_list_targets, but these are minor gaps given the low complexity.

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 schema provides no description for targetId, so the description must compensate. '可指定单台设备' clarifies that targetId is optional and selects a single device, but it does not explain where valid IDs come from or what happens if the parameter is omitted. This is partial but useful compensation.

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 clearly states the verb '运行' (run) and the specific resource: platform-specific connection diagnostics using ADB, go-ios, and official HDC. It also mentions the optional single-device target, which distinguishes it from sibling tools like mobile_list_targets, mobile_capture, and mobile_get_logs.

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 phrase '连接诊断' implies the tool is for diagnosing mobile connection issues, and the mention of specific platform tooling gives context. However, there is no explicit when-to-use/when-not-to-use guidance or direct comparison with alternatives like mobile_list_targets or mobile_get_logs.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description does not contradict them. It adds that logs are standardized native logs and filterable by level/text, but it does not disclose output format, behavior when no device is connected, or pagination. With annotations covering the safety profile, this is adequate but not rich.

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 front-loaded sentence with no wasted words. It is efficient, though slightly terse given the number of parameters and absence of an output schema.

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?

Missing output format (no output schema), meaning of preset/source enums, the required targetId role, and when to prefer sibling tools. Annotations cover the read-only/idempotent profile, but the description alone does not give an agent enough context to call the tool correctly in non-obvious situations.

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, but it only mentions level and text filtering, roughly covering 'level' and 'search'. It leaves targetId, preset, source, and limit unexplained despite six parameters and three enums. This is insufficient compensation for zero schema coverage.

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 names a specific verb ('read') and resource ('standardized native logs of the connected physical device'), and cites level/text filtering. It is clear on its own, but it does not explicitly differentiate itself from siblings such as mobile_read_evidence.

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?

No guidance is given on when to use this tool versus alternatives like mobile_read_evidence, mobile_capture, or mobile_doctor. The only clue is the tool name and the word 'logs', which leaves the routing decision 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?

Annotations already indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the 'send operations' framing is not contradictory. The description adds only 'validated' and 'selected platform adapter' context, but it does not disclose side effects, execution timing, or what happens if the operation fails.

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 compact sentence with no redundant phrases. It front-loads the operation types and background context, making it easy for an agent to parse quickly.

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 schema is rich and self-documenting, and the sibling names give useful context, but the description lacks important operational details such as how to obtain a valid targetId and what the expected result or error behavior is. With no output schema, the return semantics are left entirely unspecified.

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%, and the description does not compensate for that gap. It only restates the operation kinds already present in the 'action' oneOf schema, and it does not explain targetId, coordinate semantics, durationMs, or how the operation object should be constructed beyond what the schema already shows.

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 clearly states the tool's function with a specific verb ('发送') and resource (mobile device via platform adapter), and enumerates the concrete operation types: click, swipe, text input, and key operations. This makes it immediately distinguishable from sibling tools like mobile_capture, mobile_get_logs, or mobile_list_targets.

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 when to use this tool: whenever the agent needs to send tap, swipe, text, or key actions to a mobile target. However, it does not explicitly provide when-not-to-use guidance, name alternatives, or state that targetId should come from mobile_list_targets.

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?

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds that statuses are real-time and include connection and capability states, giving the agent expectations of freshness and scope. It does not contradict the annotations, and no side effects are implied.

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, front-loaded sentence that conveys the core action, scope, and output data with no filler. Every phrase 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, parameterless read-only listing tool, the description covers the platforms, the object type (real devices), and the reported statuses. Minor omissions like explicit return shape or whether offline devices are included are acceptable given the straightforward use case and safety annotations.

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 takes zero parameters, and the schema coverage is 100%. Per the zero-parameter baseline, no additional parameter documentation is needed; the description correctly focuses on behavior rather than inputs.

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 clear verb ('列出' / list), the resource (mobile real devices), platform coverage (Android, iOS, HarmonyOS), and the data returned (connection status and capability status). It is easily distinguished from siblings like mobile_capture or mobile_interact, which perform actions rather than enumeration.

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 using it when you need an inventory of physical mobile devices and their live status, but it does not explicitly state when to prefer it over alternatives or mention exclusions such as emulator support. There are no sibling comparisons or 'use this instead of X' guidance.

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?

注释已提供 readOnlyHint=true、idempotentHint=true、destructiveHint=false，说明这是安全的只读幂等操作，描述无需重复。描述额外披露了宿主相关的行为差异（Codex Desktop 应读取 dashboardUrl 并在内嵌浏览器打开，其他宿主使用关联的 MCP App），这对调用者理解工具的行为至关重要。不过描述没有说明打开失败时的行为或返回结果的具体结构（虽然存在输出 schema 可以补充）。

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?

该工具无参数、有输出 schema 覆盖返回值、有注释声明安全性，描述本身已覆盖宿主差异这一关键行为信息。考虑到工具复杂度低，描述在核心操作指引上是完整的。但缺少返回值包含 dashboardUrl 这一关键信息的明确说明（描述只是间接暗示'应读取 dashboardUrl'），虽然输出 schema 可能已定义该字段，但若 schema 中未明确标注则调用方可能需要额外推断。

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?

该工具参数为 0，输入 schema 为空（schema 描述覆盖率 100%），因此参数语义的负担极低。描述中提到的 dashboardUrl 是返回值的一部分而非输入参数，这实际上补充了输出语义而非输入参数语义。在无参数场景下，描述不需要解析任何参数细节，得 4 分是合理的。

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?

描述说明了这是打开移动端调试工作台的工具，使用了'打开'作为动词，资源是'cross-dev-mcp 实时真机工作台'。但描述中的关键指令'Codex Desktop 调用后应读取 dashboardUrl，并直接在右侧内嵌浏览器中打开'暗示返回值中包含 dashboardUrl，这实际上是返回值语义而非调用目的，与工具名称'打开工作台'的核心功能有一定偏差。与兄弟工具（如 mobile_capture、mobile_interact）可以区分开，但没有明确说明与这些工具的不同定位。

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?

描述区分了两种宿主环境（Codex Desktop 和其他兼容宿主）的不同处理方式，这提供了何时如何使用该工具的部分指引。但没有说明何时应该使用此工具而不是兄弟工具（如何时需要打开工作台 vs 直接使用 mobile_capture 捕获截图），也没有给出前置条件或排除场景。

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds content context (compressed/annotated screenshots and selected logs) but does not disclose return format, error behavior, or what happens for an invalid evidenceId. No contradiction with annotations.

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?

One front-loaded sentence with no filler. It states the operation, resource, and contents efficiently, so every word 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, read-only operation with strong annotations, the description covers what the tool reads and what is inside. It is adequate for invocation, though it leaves when-to-use details to the agent's inference.

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 needed to compensate for the undocumented evidenceId parameter. It never mentions evidenceId, how to obtain it, or how it selects the package; the mapping is only inferable from the field name. This is a meaningful gap for a required parameter.

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 ('读取' / read) and a specific resource ('Dashboard 暂存的证据包' / evidence package staged in Dashboard), and it enumerates the package contents. This clearly distinguishes it from sibling tools like mobile_capture or mobile_get_logs.

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 explicit guidance on when to use this tool versus alternatives, no prerequisites, and no mention of a preceding step like mobile_capture. Usage is only implied by the phrase 'staged evidence', so an agent has to infer the right timing.

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