获取配对码

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.