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

Discloses that it is a dumb pipe (A10) that forwards name/arguments without semantic understanding, and that it returns PAGE_NOT_CONNECTED when no bridge is established. With only readOnlyHint/openWorldHint annotations, this adds meaningful behavioral context, though it doesn't specify side effects (which are delegated to the target tool).

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 sentences, front-loaded with the core purpose, then scenario, mechanism, and error case. Slightly long but each clause earns its place given the nuanced fallback use case.

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?

No output schema, so the description should explain the success return and how to discover valid tool names. It mentions examples but does not direct the agent to list_page_tools for available names, nor describe the success response shape; this is a gap for a generic passthrough tool.

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; the description adds that arguments are forwarded 'as-is' and provides concrete name examples, clarifying that no transformation or validation occurs beyond 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?

States a specific verb-resource pair: explicitly calls a page-provided document tool by name, and describes the static passthrough mechanism. The examples (read_document/insert_blocks) and contrast with host-visible tools distinguish it from siblings like list_page_tools.

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 concrete applicable scenario: hosts that don't refresh tools/list, making newly paired page tools invisible. It explains why this tool exists and when to use it, though it doesn't explicitly name the alternative (e.g., using the dynamically exposed tool or list_page_tools) in a 'use X instead' form.

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=true, so the safety profile is covered. The description adds value by specifying the diagnostic contents and framing the tool as a first-stop failure investigation point, which is behavioral context beyond the annotation. No contradictions found.

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 compact sentence lists all returned status fields, and a second short clause gives the diagnostic use case. Every element earns its place, and the key payload is front-loaded before the usage note.

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 zero-parameter, read-only, diagnostic tool with no output schema, the description is complete: it enumerates the return contents, states the tool's diagnostic role, and benefits from annotations covering safety. Nothing an agent needs to decide whether and how to call it is missing.

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, so there is no parameter burden for the description to carry. With schema coverage reported at 100% and an empty properties object, the baseline of 4 applies; the description correctly adds nothing extraneous about parameters.

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 ('返回') with a clear resource ('bridge 当前状态') and enumerates the exact fields returned: listening port, bridge status, MCP session readiness, in-flight request count, Origin whitelist, and write permission. This makes the tool instantly distinguishable from sibling tools like revoke_session or call_page_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?

The description explicitly states when to reach for this tool: '工具调用失败时先查这里' (check here first when tool calls fail). It provides clear diagnostic context, though it does not name alternative tools or exclusions, so it stops slightly short of full when/when-not 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?

Beyond the readOnlyHint annotation, the description discloses substantial behavioral details: no UI is shown, no script is returned, the pairing code is used only locally for HMAC and never sent online, and the page auto-reconnects after refresh using sessionStorage. These details are valuable and not present in the 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?

The description is well-structured and front-loaded with the tool's purpose, and every sentence adds useful context such as usage, security, and reconnection behavior. It is somewhat lengthy, but the density of practical information justifies the length.

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 no-parameter tool with no output schema, the description is complete: it explains what the returned value is, how to use it, what side effects occur, how isolation works, and what happens after page refresh. An agent has enough information to invoke and apply the pairing code correctly.

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, so the description cannot add parameter-level detail. It does, however, clarify that the output is a string used as a pairing code for a challenge-response handshake, which gives meaningful semantic context for the return value.

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 and resource: it returns a pairing code string required to connect an already-open DingTalk document page to the bridge. This clearly distinguishes it from siblings like get_bridge_status, revoke_session, call_page_tool, and list_page_tools, which serve different functions.

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 explicit usage steps: the agent must run `window.__docMcpWsBridge.pair(pairingCode)` in the target page's console context. It also explains the isolation behavior (only the named page connects) and warns that the tool returns data only, never executable scripts. It does not explicitly name when not to use it versus alternatives, but the context is clear.

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=true; the description reinforces this with '只读' and adds behavior beyond annotations: results are returned as data and PAGE_NOT_CONNECTED is returned when no bridge exists. This is useful context and does not contradict the annotation.

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 front-loaded with the core return value, then gives a focused scenario, workflow, and error case in four short sentences. Every sentence contributes a distinct piece of information, with no filler.

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?

Even without an output schema, the description tells the agent what to expect: a list of tool names, descriptions, and parameter schemas, plus the not-connected error case. Combined with the usage scenario and empty input schema, nothing essential is missing for an agent to select and call 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?

There are zero parameters and the empty schema is fully covered, so there is no input-semantics burden. The description even notes that the returned inventory includes parameter schemas, but adds no input-parameter detail because none exists.

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 specific verb and resource: it returns the tool inventory (names, descriptions, parameter schemas) offered by the currently bridged page. This clearly differentiates it from call_page_tool, which is described as the follow-up invocation step.

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 explicitly gives a trigger scenario: hosts that do not refresh tools/list after page pairing, making newly exposed page tools invisible, and tells the agent to use list_page_tools first then call_page_tool. It stops short of stating when not to use the tool or comparing against the other siblings, so explicit exclusions are missing.

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=false和openWorldHint=false，描述详细说明了副作用：旧配对码失效、sessionStorage值无法重连，以及需要重新配对。无矛盾，且额外披露了内部标识S11。

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?

对于零参数工具，描述已涵盖功能、副作用、使用场景和后续操作，无输出模式但描述足够。兄弟工具列表提供了上下文，无缺失信息。

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?

工具无参数，模式覆盖率为100%，描述无需解释参数。基准为4，描述中提及需要重新调用get_pairing_code，但那是后续步骤，不影响此维度。

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?

描述明确说明了动词（轮换、断开）和资源（配对码、页面会话），并区分了兄弟工具（get_pairing_code等）。明确表示撤销后旧配对码失效，会话断开。

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?

描述了使用场景（结束授权或怀疑泄露），并指出需要重新调用get_pairing_code配对。但未显式说明何时不使用，不过基于兄弟工具列表，其他工具不执行撤销操作，因此清晰度足够。

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