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

With no annotations, the description carries the full burden and does well: it discloses that acceptance joins the other party's room, that an opening statement is returned, and imposes a consent gate before the mutating action. It does not mention authentication or what happens on failure, but the key side effects and the pre-condition are clear.

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?

Compact and front-loaded: purpose first, then the consent rule, then the follow-up workflow. Every clause earns its place, though the follow-up instructions make the sentence dense.

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 exists, and the description compensates by explaining what is returned (the opening statement / task background) and what to do with it. The consent prerequisite and post-call workflow round it out; only error/failure behavior is unaddressed.

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 100%, so the schema already documents 'from' (optional when only one invitee) and 'accept_files'. The description adds no parameter-level detail, so baseline 3 applies.

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 ('接受一个联系人的邀请：加入它开的房间，返回它的开场白'), and explains the return value in domain terms (task background). It clearly distinguishes itself from agenthop_decline by naming the accept-and-join semantics, though it never explicitly contrasts with the decline sibling.

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?

Explicit about when to call: tell the user about the invitation first and get consent, unless the user pre-authorized auto-acceptance. It also prescribes the follow-up workflow (read the opening, then use agenthop_say if it matches) and references agenthop_join as the comparable pattern.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the other side will return the farewell and then both sides end, which is non-obvious protocol context. However, it does not cover failure modes, timeouts, blocking behavior, or permission requirements.

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 two short sentences with no wasted words. It front-loads the main action and then adds the interaction protocol, making it easy to scan.

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 tool with a fully described schema and no output schema, the description covers purpose and the key end-of-conversation protocol. It does not address edge cases or alternatives, but those are minor relative to the tool's 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?

Schema description coverage is 100%, and the sole parameter is an optional farewell text. The description restates that the text is optional and is a farewell, matching what the schema already provides without adding syntax or format details. Baseline 3 is appropriate when the schema does the heavy lifting.

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 and resource: ending a conversation, with an optional farewell message. It also describes the expected handshake behavior, which makes the tool's scope clear. It does not explicitly distinguish itself from sibling tools such as agenthop_say or agenthop_wait, so it stops short of a 5.

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?

Usage is implied: call this when you want to end the conversation, optionally with a farewell. There is no explicit when-not-to-use guidance or named alternative among the sibling communication tools. This is adequate but leaves routing 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?

With no annotations provided, the description carries the full behavioral burden; it does disclose the concrete contents returned (names, fingerprints, online flag, pending invites), which is useful. However, it never states that this is a non-mutating read, whether any auth or network state is required, or anything about pagination or failure modes.

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 compact sentence that front-loads the verb and lists the returned items with no filler. Every clause conveys payload content.

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?

Because there is no output schema, the description must convey what comes back, and it does enumerate the returned fields well for a zero-argument read tool. The main gap is the absence of routing guidance relative to the many similarly-scoped sibling tools.

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 effectively 100%, so there is nothing for the description to clarify. Baseline 4 applies for a parameterless tool.

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) and enumerates the concrete resources returned: contacts with name and fingerprint, the local node's own fingerprint, whether the inbox address is online, and pending invitations. It is specific, though the bundling of several distinct resource types into one tool makes the boundary a bit fuzzy, and no sibling (e.g. agenthop_status) is named or excluded.

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?

There is no indication of when to call this versus alternatives, despite overlapping siblings such as agenthop_status, agenthop_wait, and agenthop_invite. No prerequisites, no context, no exclusions are given.

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?

With no annotations, the description carries the full burden and does disclose non-obvious behavior: the tool returns a pairing code that must be relayed verbatim, and background is transmitted as an opening message the other side uses to verify identity. It omits lifecycle details such as room expiry, failure modes, or whether the call blocks, which keeps it out of the top band.

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?

Front-loaded with the action and its return value, then the handoff flow, then parameter meaning. Every clause carries information, though the delivery is slightly dense with several flow steps packed into one sentence.

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 tool with no output schema and no annotations, the description covers purpose, the returned artifact, the cross-agent handoff workflow, and the meaning of the required parameter. The gap is lifecycle/error behavior and the significance of accept_files, the latter partly mitigated by the 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: background is '这次要谈的事' and is delivered as an opening message that the counterpart uses for identification, going beyond the schema's bare '这次对话的任务背景'. It says nothing extra about accept_files, which the schema already documents.

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 and resource ('开一个房间' / open a room) plus the concrete result ('返回配对码' / returns a pairing code). It explicitly names the sibling that the counterpart agent must use ('对方的 agent 用 agenthop_join 加入'), so an agent can distinguish create from join without reading either schema.

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 lays out the usage context clearly: hand the whole pairing code to the user, who forwards it to the other party, whose agent joins via agenthop_join. The alternative (join) and its actor are named, but there is no explicit when-not-to-use or precondition beyond the handoff flow.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the other party will know immediately ('对方会马上知道，不用干等'), but it does not cover other relevant traits such as whether the decline is permanent, how the reason is delivered, or any permission requirements.

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 two short, front-loaded sentences with no wasted words. It states the action and the optional reason first, then notes the immediate notification, making it efficient and easy to parse.

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 two-parameter communication tool with complete schema descriptions and no output schema, the description covers the core purpose and a key behavioral outcome. It is nearly complete, though with no annotations it could have added slightly more about side effects or permission context.

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 100%, so both parameters are already documented in the schema. The description mentions that a reason can optionally be included, which aligns with the reason parameter, but adds no syntax or format details beyond what the schema provides.

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 in Chinese: declining a contact's invitation. This is clearly distinguishable from sibling tools like agenthop_accept and agenthop_invite, which handle accepting and sending invitations respectively.

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 the usage context by stating it declines a contact's invitation, but it does not explicitly say when to use this tool versus alternatives such as agenthop_accept, nor does it list exclusions or prerequisites. The intended use is inferable but not fully guided.

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?

No annotations are provided, so the description carries the full burden. It does usefully disclose post-deletion consequences (future invitations rejected, cannot invite by name again), but omits whether the action is reversible, what happens to existing invitations or message history, and any permission requirements.

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?

Two short sentences, front-loaded with the action and then its consequence. Nothing is padded, though the extreme brevity leaves room for the missing behavioral context noted above.

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 destructive operation with no annotations and no output schema, the description should ideally cover reversibility and side effects on related state. It covers the key follow-on effects but leaves those other gaps open.

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 100% and there is only one string parameter ('name'), so the schema fully documents it. The description adds no syntax or format detail beyond the schema, making 3 the correct baseline.

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 and resource ('删掉一个联系人' = delete a contact), which is unambiguous. It does not distinguish itself from siblings like agenthop_decline or agenthop_bye, which also remove a relationship, so it falls short of a 5.

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 when-to-use guidance or alternatives are given. Against siblings such as agenthop_decline, agenthop_bye, and agenthop_save_contact, the agent gets no help deciding when forgetting is the right action versus simply declining.

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?

With no annotations, the description carries the behavioral load: background becomes the opening statement, the recipient must have agenthop open, offline results in an immediate notification, and the sender should use agenthop_wait afterwards. It does not cover safety (destructive? reversible?) or authentication requirements, but provides substantial interaction context.

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, each with a clear role: purpose, background semantics, precondition, and follow-up. No redundant text, though the description is slightly verbose.

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 an async invite tool with no annotations or output schema, the description covers how to call, the precondition, and the next step. It omits return values and other error cases, but is mostly complete for an agent to invoke 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?

Schema coverage is 100%, so baseline is 3. The description adds semantic meaning for 'background' by explaining it is the conversation topic and will be delivered as an opening statement. For 'name' and 'accept_files' it adds nothing 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?

The description states a specific verb ('邀请' invite) and resource ('联系人对话' contact conversation) and distinguishes the mechanism from pairing-code flows ('不用转交配对码'). It makes clear that this tool invites a contact by name, which is distinct from join/create siblings.

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 names the follow-up tool agenthop_wait and specifies the precondition that the recipient's agent must be online. It does not explicitly compare to other invite/join tools, but the context and follow-up instruction provide clear usage 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?

With no annotations, the description carries the full burden and does well: it discloses that the call blocks/wits for the counterpart's opening remark before returning, and that the channel only opens after a confirmation via agenthop_say. It does not, however, mention permissions, timeouts, or failure behavior while waiting.

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?

Front-loads the action (join via code) before the conditional workflow, and every clause is functional. It is slightly long as a single run-on with multiple semicolon-linked steps, but no sentence is wasted.

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, the description adequately explains what is returned (the counterpart's opening remark) and what to do next. For a 2-parameter workflow entry point it is nearly complete, though it omits error/timeout handling.

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 both parameters are already documented by the schema. The description only reiterates the pairing code concept and says nothing about accept_files or file-storage semantics, so it adds no meaning beyond the structured fields. Baseline 3 is appropriate.

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 ('用配对码加入对方的房间') with the exact trigger (a pairing code) and the full return behavior ('等到对方的开场白...后返回'). It clearly distinguishes itself from siblings by naming agenthop_say as the follow-up action, so an agent can identify this as the room-joining step of a workflow.

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?

Provides explicit branching: if the opening remark matches the context, call agenthop_say to confirm and the channel opens; if it does not match, ask the user and do not reply. This names the alternative tool and the condition selecting it, leaving nothing 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses a key constraint: the other party must also save you as a contact for invitations to be accepted. However, it omits other relevant details such as persistence, error handling, idempotency, or how saved contacts are managed. This is adequate but leaves clear gaps.

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 three concise sentences, front-loads the core purpose, then states the benefit and the mutual precondition. Every sentence earns its place and no information is wasted.

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?

Given the low complexity (one parameter, no output schema, no annotations), the description covers the essential purpose, usage context, and the critical mutual-save precondition. It does not explain success/failure outcomes or contact management, but those are minor for this simple 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?

The input schema has 100% description coverage for the single parameter 'name', including an example. The description does not add any additional meaning or syntax beyond what the schema already provides, so the baseline score of 3 is appropriate.

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: saving the other party in the current conversation as a contact. It also names the sibling tool agenthop_invite as the follow-up action, helping the agent distinguish this tool from others like agenthop_forget_contact.

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 clearly indicates when to use it: for a conversation that is ongoing or just ended, to enable future invitations by name without sharing pairing codes. It doesn't explicitly list when not to use it or mention alternatives like agenthop_contacts or agenthop_forget_contact, but the context is sufficiently 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that the tool returns whether delivery succeeded and that multi-line text is allowed, but says nothing about permissions, failure/retry semantics, queueing, or message limits.

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 short clauses that each carry distinct information: purpose, return value, the joiner special case, and the sibling alternatives. Front-loaded and free of padding.

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 one-parameter message tool with no output schema or annotations, the description covers purpose, return indication, and sibling routing. A bit more on delivery failure behavior would make it fully self-sufficient.

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 is only one parameter and schema description coverage is 100%, so the schema already documents 'text'. The description adds marginal value by stating the text may span multiple lines, which is not expressed in the schema, but nothing else about format or length.

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 gives a specific verb+resource (say something to the other party) and explicitly bounds the input shape (can be multi-line). It distinguishes itself from siblings by naming agenthop_working and agenthop_bye for other roles, though it never explains the broader messaging model or how it differs from agenthop_send_file.

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 routes the agent to alternatives for adjacent actions — agenthop_working for receipts and agenthop_bye for ending — and clarifies that a joiner's first message serves as confirmation of the opening statement. It gives clear context but no explicit when-not or ordering guidance for the core message case.

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?

With no annotations, the description carries the full burden and does well: it discloses the 512 KiB cap, end-to-end encryption of both content and filename, that the relay cannot read them, and the recipient's opt-in precondition with its degraded fallback. It stops short of describing error/rejection handling or whether the send is confirmed.

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 dense sentence that front-loads the action and size limit, then layers encryption and delivery semantics. Every clause earns its place, though the clause chain makes it slightly less scannable.

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 or annotations exist, so the description must cover behavior, and it does cover limits, encryption, and recipient-side acceptance. What is missing is the outcome on rejection or failure, which an agent would want before calling.

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?

Only one parameter (path) exists and the schema already documents it at 100% coverage as the local file path. The description adds no format, resolution, or validation detail beyond the schema, so the baseline 3 is appropriate.

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 and resource (send a file to the other party) plus a hard size limit, which distinguishes it immediately from the sibling chat-style tools like agenthop_say. An agent can tell what the tool does without inspecting the schema.

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 implies when the tool applies (transferring a local file rather than a message) and gives a useful usage condition: the counterparty must have allowed file receiving when creating or joining the room, otherwise only the filename is recorded. However, it never explicitly contrasts this with alternatives such as agenthop_say for content delivery or describes failure behavior.

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?

No annotations are provided, so the description carries the full disclosure burden. The word '看' (view) implies a read-only, side-effect-free operation, and the enumerated return contents give useful behavioral context. It does not, however, explicitly confirm it is non-mutating, mention permissions, or describe the response shape, leaving gaps for a tool with zero annotation coverage.

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 with the core purpose first, followed by a compact enumeration of the returned items. No wasted words; the density is appropriate for a status readout, though the semicolon list is slightly cramped.

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, the description usefully enumerates what the caller gets back (step, pairing code, log path, identity, address, pending invites), which compensates for the missing return definition. Given a zero-param tool, this is largely complete, with only explicit usage/alternative guidance 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 the baseline is 4. There is nothing parameter-related for the description to clarify, and it correctly does not invent any.

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 clear verb (看/view) and enumerates the concrete contents it reports: current step, pairing code, log location, local identity, receiving address, and pending invitations. This distinguishes it well from action-oriented siblings like agenthop_say or agenthop_send_file, though it does not explicitly name an alternative. It is a specific, resource-scoped status 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?

Usage is implied: an agent should call this to inspect the current conversation state and local identity. However, there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives among the many siblings (e.g. agenthop_contacts, agenthop_wait). Minimal viable guidance only.

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?

With no annotations provided, the description carries the burden well: it explains blocking/return semantics, states that all new activity including working progress is returned, and covers timeout retry and invitation waiting. It does not mention permissions or side effects, but for a wait operation this is largely sufficient.

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 front-loads the core purpose and then gives return conditions, timeout behavior, and the invitation case in short sentences. There is little wasted wording, though it could be marginally tighter.

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?

Given one simple optional parameter, no annotations, and no output schema, the description sufficiently covers return triggers, returned content, retry behavior, and the no-conversation case. It does not define the exact return shape, but it is complete enough for an agent to invoke 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?

Schema description coverage is 100%, and the timeout_seconds parameter already documents its default and bounds. The description mentions timeout only generically and adds no parsing or format meaning beyond the schema, so the baseline 3 is appropriate.

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?

It states a specific verb and resource ('等对方说话') and enumerates return triggers (other party speaks, confirms, says goodbye, or timeout), making the core purpose clear. However, it does not explicitly name or differentiate from sibling tools such as agenthop_status or agenthop_working, so it falls short of a 5.

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 gives clear usage context: retry after a timeout and the special case where no conversation is active, in which case it waits for a contact invitation. It does not explicitly state when not to use it or name alternatives, but the intended usage is well conveyed.

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?

With no annotations, the description carries the full behavioral burden and does well: it explains how the message is perceived (progress, not a turn requiring response), the social effect (the peer waits instead of assuming you went offline), and the ordering constraint relative to the work. It does not disclose any return value or delivery/broadcast semantics, which are gaps but minor for this signaling 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?

Three short sentences, front-loaded with the core action ("回一张收条"), followed by rationale and timing. The middle sentence on how the peer perceives the message is slightly expansive but earns its place by justifying why this differs from a normal reply.

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 one-parameter, zero-required tool with no annotations and no output schema, the description supplies the missing usage timing and behavioral intent, which is enough for an agent to call it correctly. Only delivery/visibility details are absent.

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 100% and the single optional 'text' parameter is already documented with an example, so the baseline is 3. The description implies what the text should convey (what you're doing, roughly how long) but adds no syntax or format detail 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 action — returning a receipt/acknowledgment that you received a message and are working on it — and contrasts it with a message that expects a reply, which distinguishes it from the conversational sibling agenthop_say. It never names a sibling tool explicitly, so the distinction from agenthop_status or agenthop_say is inferred rather than stated.

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 clear, actionable timing: call it immediately after receiving a message, before starting work. It stops short of naming alternatives or stating when NOT to use it, so it is clear context without explicit routing.

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