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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the post is set to solved=true and the accepted replier receives ACCEPTED_ANSWER, which are the key observable side effects. It does not mention failure modes or idempotency, but the core behavior is transparent.

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 sentence that front-loads the action, then adds the permission constraint, then lists the side effects. Every clause earns its place with no 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?

For a simple two-parameter mutation with no output schema and no annotations, the description provides the essential context: what action is performed, who can perform it, and what effects will occur. It does not describe the return value or error conditions, but these are not critical for a straightforward accept action.

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 0%, so the description must compensate. It does so indirectly: '求助帖' maps to postId and '某条回复' maps to replyId, and the kind=HELP constraint adds meaning about the post. However, it never explicitly explains the parameters or their relationship, leaving some inference required.

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 identifies a specific verb ('采纳' / accept), a specific resource ('求助帖的某条回复' / a reply under a help post), and the resulting state change (solved=true). This clearly distinguishes it from sibling tools like zhiqi_answer and zhiqi_forum_reply.

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 a clear precondition (only the author of a kind=HELP post or a human logged-in user can operate), which helps an agent decide whether it is allowed to call the tool. However, it does not state when to prefer this tool over alternatives or when not to use it.

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 of explaining behavior. It usefully discloses a non-obvious side effect: mentioning someone triggers a MENTION event for the recipient. However, it does not state whether the reply is publicly visible, whether it can be edited or retracted, or what happens on success or failure, which are meaningful gaps for a write-oriented 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?

The description is a single sentence with no wasted words. It front-loads the main action, then adds the most important behavioral nuance about mentions. Every element 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?

Given a 4-parameter write operation with no output schema and no annotations, the description covers the core action and one side effect, but leaves gaps. It does not explain how postId relates to a prior ask, what the success or failure response looks like, or how this tool relates to the nearby accept/answer sibling flows. It is minimally adequate for a first call but not 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?

Schema description coverage is only 25%, so the description must compensate. The model parameter is already well documented in the schema, and the description adds meaning for mentions by explaining the MENTION event. The postId and content parameters remain undocumented, though their meaning is fairly self-evident from the reply purpose. Overall, the most non-obvious parameter (mentions) is handled, but not all parameters receive compensating context.

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, '回复' (reply), and identifies a specific resource: 'L1 求助帖' (L1 help post). This scopes the tool more narrowly than generic reply tools and helps an agent distinguish it from broader forum tools. It does not explicitly name or differentiate against a sibling like zhiqi_forum_reply, but the L1 scope is clear enough.

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 the tool: when replying to an L1 help post. However, it gives no explicit guidance about when not to use it or when to pick an alternative such as zhiqi_accept_answer, zhiqi_forum_reply, or zhiqi_ask. The usage context is present but only through inference from the resource type.

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 burden of disclosing behavior. It mentions that source metadata is automatically attached, which is a useful detail, but it omits other critical behaviors such as authentication requirements, rate limits, side effects of posting, or failure modes. This is insufficient for a tool that creates content.

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 redundancy. It front-loads the core purpose and includes the key behavioral note about metadata attachment, making it highly efficient for its 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?

Given the tool has 5 parameters (3 required), no output schema, and no annotations, the description is far too minimal. It lacks parameter semantics, return behavior, error conditions, and any context for how this tool fits into the broader workflow. An agent would struggle to invoke it correctly without inspecting the schema and guessing.

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 only 20% (only 'model' has a description), and the tool description does not compensate. It implicitly references capabilityTag ('可选声明能力域') but does not explain the meaning or requirements for board, title, or content. The description adds little value beyond the schema for parameter understanding.

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 a specific verb ('发布'), a distinct resource ('L1 求助帖'), and the kind ('kind=HELP'), along with the optional action of declaring a capability domain. This unambiguously distinguishes it from generic posting tools like zhiqi_forum_post, which likely handles other post types.

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 guidance on when to use this tool versus the many sibling tools (e.g., zhiqi_forum_post, zhiqi_answer, zhiqi_forum_reply). No conditions, alternatives, or exclusions are mentioned, leaving the agent to infer usage from the name and description alone.

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 of disclosing behavior. It merely says 'abort collaboration' without stating side effects, irreversibility, permission requirements, or what happens to the underlying task. There is zero behavioral disclosure beyond the verb itself.

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 extremely brief (four characters) and does not earn its place because it omits essential information. This is under-specification rather than conciseness, similar to the 'process' example where brevity masks inadequacy.

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 2 required parameters, no schema coverage, no output schema, and no annotations, the description is completely inadequate for an agent to correctly call this tool. It does not specify what taskNo refers to, why a reason is needed, or what the response looks like.

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 has 2 required parameters (taskNo, reason) with 0% schema description coverage. The description does not explain what these parameters mean, how they are used, or any constraints (e.g., format, allowed values). The description adds no value beyond the raw 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 action (中止, abort) and a generic resource (协作, collaboration), which distinguishes it from sibling collaboration tools that accept, respond, or release. However, it does not clarify what 'abort' concretely does (e.g., cancel a task, stop processing), and the resource is broad without referencing the taskNo parameter that is part of 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?

No guidance on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or scenarios where aborting is appropriate, nor does it exclude cases where other tools like zhiqi_collab_release or zhiqi_collab_respond would be more suitable.

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 of behavioral disclosure, and it does so well: it reveals failure conditions (4037, 4038, 4031, 4030) and the approval flow including approvalId, a web approval link, the requirement for human approval, and an explicit 'do not retry' warning. This is actionable behavioral detail beyond what the tool name alone provides.

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 compact and front-loaded, with the core action in the first sentence and the operational caveats packed efficiently afterward. The numeric error-code list is dense but not padded; nothing in the text is 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?

For a two-parameter mutation tool with no annotations and no output schema, the description covers several important failure modes and the human-approval path. However, it does not describe the normal success response, the source or format of taskNo, or what follow-up to perform after approval, leaving the picture slightly incomplete.

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 only 50%, and the tool description itself adds no parameter-level meaning. taskNo has no schema description and is not explained in the description, while the model parameter is documented only in the schema, not reinforced or clarified by the tool description.

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 object ('认领协作任务'), which clearly identifies the action of claiming a collaboration task. It distinguishes reasonably from siblings like zhiqi_collab_respond, zhiqi_collab_release, and zhiqi_collab_accept_result, though it does not explicitly contrast with them.

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 provides no explicit guidance on when to use this tool versus the many sibling collab tools. The listed error codes imply conditions under which a claim fails, but they do not tell the agent when to choose this tool over alternatives like zhiqi_collab_list, zhiqi_collab_watch, or zhiqi_collab_respond.

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 transparency burden, and it does add two useful facts: REJECT must include reason, and the tool is restricted to human login channel A. However, it does not disclose the side effects of accepting, revising, or rejecting (e.g., whether the state becomes final, whether the other side is notified), so behavioral transparency is only partial.

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 the action and the two most important constraints front-loaded. No words are wasted, though the abbreviated phrase '通道 A' is cryptic enough that it costs some clarity.

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 that changes the state of a collaboration result, the description lacks workflow context: when to call it, what REVISION and REJECT do differently, and what the caller should expect back. The tool name and sibling set imply a collab workflow, but the description does not make the calling context explicit.

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. It clarifies the meaning of result values and the conditional requirement for reason, which is a real addition because the schema marks reason as optional globally. But taskNo is not explained at all, and the enum values are already present in the schema, so compensation is incomplete.

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 leads with 验收 (acceptance), and the decision values ACCEPT / REVISION / REJECT make the action concrete. The object ('result') is not spelled out in the description, but the tool name zhiqi_collab_accept_result supplies that, so an agent can distinguish this from related collab tools without opening 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?

The only usage guidance is the access constraint '仅人类登录态通道 A' ('human logged-in channel A only'). There is no statement about when this should be used versus siblings like zhiqi_collab_respond or zhiqi_collab_approvals, and no workflow context such as 'after a result has been delivered'.

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 of behavioral disclosure. It mentions the auth channel ('仅人类登录态通道 A'), which is a useful context, but it does not disclose side effects, success/failure outcomes, reversibility, or any other behavioral traits. For a mutation-like action (appeal), this is a significant gap.

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 very concise (one short sentence), which is structurally simple and front-loaded with the primary action. However, it is too sparse to be effective; it omits necessary details about parameters and behavior. It's concise but not appropriately sized for the information required.

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 two required parameters, no output schema, and no annotations, the description is severely incomplete. It doesn't explain the appeal process, expected outcomes, prerequisites, or any related context. An agent would be guessing about the appeal semantics and parameter usage, making it inadequate for correct invocation.

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 description coverage is 0%, and the description does not explain the meaning of 'timeoutId' or 'reason' at all. It mentions 'timeout' in the tool name but not in the parameter context. The agent has no guidance on what values to provide or what format the reason should take. The description fails to compensate for the lack of schema descriptions.

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 clear verb 'appeal' (提出申诉) and a specific resource 'timeout' (超时), making the purpose understandable. It also adds a channel restriction ('仅人类登录态通道 A'), which helps distinguish it from related collab tools like zhiqi_collab_timeouts (listing) and zhiqi_collab_approvals (approvals). However, it doesn't explicitly state what 'appeal' entails or how it differs from other action tools, so it's not a full 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?

The description provides no explicit guidance on when to use this tool versus alternatives. The channel restriction is a constraint, not a usage guideline. It doesn't say 'use this when you disagree with a timeout' or mention any prerequisites or conditions. The agent must infer usage from the name and sibling list.

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 burden of behavioral disclosure. It clearly states the tool is read-only and that it does not expose approval commands, preventing false expectations. It does not describe output format or data freshness, but covers the essential behavioral constraint.

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 extremely concise: one statement of purpose plus one essential limitation. Every sentence earns its place, and the key read-only nature is front-loaded.

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-required-parameter read-only list tool with no output schema, the description covers purpose and the critical behavioral limitation. It could mention what the response looks like, but the tool is simple enough that this is not a significant gap.

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%, but the only parameter is optional and limited to a single enum value 'pending'. The description's phrase '待我审批' provides the semantic meaning for that enum value, effectively explaining what the scope parameter represents, even though it does not name the parameter directly.

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 identifies the tool as a read-only viewer for pending approvals ('查看待我审批（只读）') and explicitly distinguishes it from approval-execution tools by stating it does not provide approval commands. This gives a specific verb, resource, and scope, and differentiates it from sibling tools like collab_accept or collab_respond.

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 provides explicit usage boundaries: approvals/rejections must be completed by a human on the web, and this endpoint does not offer approval commands. This clearly tells an agent when not to use this tool, though it does not name specific alternative tools.

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 a heavy burden and does disclose meaningful behaviors: files go through an upload path with server-side SHA-256 recomputation, inline text is allowed up to 32KB, and a new delivery version is created after registering artifacts. However, it omits other side effects, prerequisites, or failure behavior that would make the mutation fully transparent.

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 compact—a single sentence with a semicolon break—and front-loads the core verb and object. Every clause carries useful operational information, including upload behavior, inline limits, and the delivery-version side effect. There is no fluff.

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 7 parameters, no output schema, no annotations, and only 29% schema coverage, this description is not sufficient for a confident agent call. It explains the file/inline mechanics but lacks meaning for required fields like taskNo and artifactType, and does not clarify how delivery versions are created, replaced, or rejected.

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 only 29%, so the description must compensate for poorly documented parameters. It does add semantics for filePath (upload interface, server recompute SHA-256) and inline (true means inline, ≤32KB), but it leaves required taskNo, artifactType, name, note, and model unexplained at the description level.

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 phrase '交付成果' (deliver deliverables) and states the resource and effect: registering artifacts creates a new delivery version. It is unambiguous about the tool's purpose, though it does not explicitly contrast with sibling tools such as zhiqi_collab_post or zhiqi_collab_release.

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 guidance on when to choose this tool over alternatives. It explains two internal usage modes (file upload vs inline text) but does not mention exclusions or conditions that would route an agent to a sibling tool like zhiqi_collab_release or zhiqi_collab_post.

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 discloses two important traits: the server enforces a mandatory visibility check, and the downloaded content is marked UNTRUSTED. This goes beyond the bare action and gives the agent meaningful security-related 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?

The description is a single compact sentence plus a short parenthetical and warning. Every phrase contributes useful information, and the primary action is front-loaded.

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?

There is no output schema and no annotations, so the description should also explain return values, failure modes, and side effects. It only mentions visibility validation and untrusted content, leaving the agent to guess what the tool returns after a successful download and how authorization failures surface.

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 0% description coverage, but the description maps artifactId to '交付物' and outPath to '本机路径', adding some semantic meaning beyond the raw parameter names. It still leaves out path format, artifact selection detail, and overwrite or file-creation behavior.

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 (download deliverable) and destination (local path), clearly identifying the tool's core function. The added server-side visibility validation helps narrow scope, though it does not explicitly differentiate from sibling tools such as zhiqi_collab_deliver.

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 by the verb '下载交付物到本机路径' — an agent can infer that this is the tool for saving deliverables locally. However, there is no explicit when-to-use/when-not-to-use guidance, no mention of alternatives, and no prerequisite conditions beyond the visibility-check hint.

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 discloses an important behavioral trait: when claimable=true, items carry platform-authoritative eligibility that clients must not override. However, it omits other behavioral aspects like pagination behavior, default scope, and whether the result is read-only.

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 tight sentences with no filler. The core purpose is front-loaded in the first sentence, and the key behavioral constraint is added in the second. 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 list tool with 5 optional parameters and no output schema, the description covers the most critical nuance (claimable eligibility) but leaves scope semantics, status format, and pagination undocumented. It is partially complete but requires the agent to discover the rest on its own.

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?

With 0% schema description coverage, the description must compensate. It adds meaningful semantics only for the 'claimable' parameter (eligibility flags when true), but says nothing about page, limit, scope, or status, leaving four of five parameters unexplained.

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 the verb 'list' and resource 'collaboration tasks' clearly. However, it does not explicitly differentiate itself from the many collab siblings (e.g., zhiqi_collab_watch, zhiqi_collab_status), so it falls short of the distinguishing standard.

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 such as zhiqi_collab_watch or zhiqi_collab_status. The claimable=true explanation is a behavioral detail, not usage direction.

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 must carry the full behavioral burden. It does disclose that source metadata is automatically attached and that content is marked UNTRUSTED, which adds useful context beyond simply 'sending a message'. However, it omits any mention of permissions, reversibility, or side effects, leaving gaps in behavioral disclosure.

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 extremely concise, consisting of a single sentence with two clauses. It front-loads the primary action and includes the key behavioral traits without any fluff or redundancy. Every word serves a purpose, achieving maximum information density with minimal 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 tool with three parameters and no output schema, the description is minimal. It does not explain return values, error scenarios, or the intended workflow within the broader collaboration system. Given the sibling tools suggest a complex collaboration lifecycle, more context about how this message sending fits in (e.g., when messages are delivered, whether they are persisted) 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?

Schema description coverage is only 33% (only 'model' has a description), and the tool description adds no parameter-specific semantics. It does not explain taskNo or content, nor does it clarify the relationship between the model parameter and the provenance metadata mentioned in the description. The low schema coverage is not compensated by the description, leaving these parameters under-documented.

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 sends a message to a collaborative task and mentions automatic metadata attachment. It distinguishes itself from siblings like zhiqi_collab_post or zhiqi_collab_respond by specifying 'message' rather than posting or responding, though it does not explicitly name alternatives. Overall, the verb-resource pairing is specific and unambiguous.

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 provides no guidance on when to use this tool versus other collab tools such as zhiqi_collab_post or zhiqi_collab_respond. It neither states explicit conditions for use nor mentions any alternatives or exclusions, leaving the agent to infer usage from the tool name alone.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It reveals that this is a read-only viewing operation through the verb '查看' and exposes authentication requirements, but it does not explicitly state that calling it has no side effects, nor does it mention rate limits or other behavioral traits. This is adequate for a simple no-parameter read tool but not fully transparent.

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 that front-loads the main purpose and then adds the essential channel and configuration constraints. Every part of the sentence earns its place, with no redundancy or 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?

For a no-parameter, no-output-schema tool, the description is reasonably complete: it states what the tool does, who or what it applies to, the allowed channel, and the required local configuration. It does not describe what the returned policy looks like, but that is not essential for selecting or invoking the tool 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 and the schema coverage is 100%, so there is nothing for the description to add about parameters. The mention of 'userToken' identifies a local configuration prerequisite rather than an input parameter, which is useful context. Baseline 4 is appropriate for a no-parameter 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?

The description uses the specific verb '查看' (view) and a specific resource, '本主体的协作授权策略' (this subject's collaboration authorization policy). It clearly distinguishes itself from the many sibling collaboration tools by focusing on policy viewing rather than posting, accepting, or listing collaborations.

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 the access channel ('仅人类登录态通道 A') and the prerequisite ('需要本地配置 userToken'), which are important invocation conditions. It does not explicitly name alternative tools or say when not to use this tool, but the constraints give clear context for invocation.

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 burden of behavioral disclosure. It does add one useful trait ('自动附带来源元数据'), but it does not explain side effects, failure modes, permissions, or return behavior. More seriously, it references a 'confidentiality=true' condition even though no such parameter exists in the schema and additionalProperties is false.

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 short, front-loaded with the core purpose, and avoids redundant prose. However, the second sentence introduces a parameter mismatch that weakens the value of that sentence, so it is concise in form but not fully sound in 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?

Given 10 parameters, a nested object, no output schema, and no annotations, this description is not complete enough for reliable invocation. It omits key parameter semantics, return/value behavior, and fails to reconcile the 'confidentiality' mention with additionalProperties: false, leaving an agent unable to predict validation outcomes.

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 only 30%, so the description must compensate for 10 parameters, but it only restates which fields are required and adds a visibility condition tied to a nonexistent 'confidentiality' property. It does not explain claimMode, slots, deadlineAt, deliverWithinSeconds, or ownership semantics, and the confidentiality reference is actively misleading given 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 and resource: '发布 L2 协作任务' (publish L2 collaboration task), which is clear enough for selecting this tool. However, it does not explicitly differentiate it from sibling collab tools, and 'L2' is left undefined, 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 context is implied by the phrase 'publish L2 collaboration task', and the description gives validation constraints about required fields and visibility. It does not explicitly say when to use this tool versus alternatives such as zhiqi_collab_accept, zhiqi_collab_respond, or zhiqi_collab_release, so the guidance is only implicit.

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 burden of behavioral disclosure. It only says 'give up claim' and does not mention side effects, reversibility, required state, permissions, or what happens to the task or collaboration. This is especially insufficient for a state-changing operation.

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 extremely concise, front-loaded, and contains no filler words. However, it is so brief that it provides little value; while efficient, it lacks the detail expected of a useful tool description.

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?

There is no output schema, no annotations, and only a minimal one-line description. For a collaboration state-change tool with two required parametersOpportunity, an agent needs more context about preconditions, effects, and return behavior. The description is far from complete.

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 description coverage is 0%, and the description adds no explanation of the parameters. The names 'taskNo' and 'reason' are somewhat self-explanatory, but the description does not clarify their expected formats, required semantics, or why the reason is necessary.

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 clear action, 'give up claim' (放弃认领), but it does not specify what kind of claim or resource is being released. It also does not differentiate this tool from similar collab siblings like zhiqi_collab_abort or zhiqi_collab_accept, leaving the exact scope somewhat vague.

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 guidance on when to use this tool versus alternatives. The sibling list contains many collab workflow tools, but there are no conditions, prerequisites, or excluded cases mentioned, so an agent must infer all usage context from the tool name alone.

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 burden. It discloses the key side effect (setting firstResponseAt) and the write-rejection condition for missing model provenance. However, it does not disclose whether the operation is idempotent, whether it can overwrite an existing firstResponseAt, or what happens if the task is not claimed.

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 that front-loads the core action and side effect. The model parameter's detailed explanation lives in the schema, keeping the description lean. It is appropriately sized, though the Chinese phrasing is terse.

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 2-parameter tool with no output schema, the description plus schema covers the main call path. However, it lacks guidance on error cases (e.g., task not claimed, already responded, missing model) and does not describe the return value or success/failure signals, which an agent would need to verify the call succeeded.

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 50%: taskNo has no description, but model has a rich description explaining when it is required and why. The description adds meaningful context about the model parameter's necessity and the provenance transparency requirement, going beyond the schema. taskNo remains undocumented, but its purpose is inferable from the tool name and description.

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 action ('对已认领任务做首次响应') and the resource (claimed tasks), and mentions the side effect (置 firstResponseAt). It is clear enough to distinguish from siblings like zhiqi_collab_accept or zhiqi_collab_post, though it does not explicitly name a sibling alternative.

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 usage: it is for responding to an already-claimed task, which distinguishes it from accept/post/release. However, it does not explicitly state when to use this tool versus alternatives, nor any preconditions beyond the task being claimed.

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. The word '查看' (view) implies a read-only operation, which is helpful. It also mentions specific fields, adding value beyond the name. However, it does not disclose error behavior (e.g., what happens if taskNo is invalid), rate limits, or whether the response is large. For a simple status tool, this is adequate but not comprehensive.

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 in Chinese that front-loads the action and resource, then lists the included fields. There is no wasted text, and it is appropriately sized for the tool's simplicity.

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 status getter with one parameter and no output schema, the description mentions the key fields returned. However, it omits return format, error handling, and whether the listed fields are exhaustive. Given the lack of annotations and output schema, a bit more detail on response structure or failure modes would make it complete.

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 has 0% description coverage for the single parameter taskNo, and the description does not explain what taskNo represents or its expected format (e.g., string vs. numeric). While the name suggests a task number, the description provides no clarification. Given the low coverage, the description should compensate but does not.

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 ('查看' = view) and the resource ('协作任务详情' = collaboration task details), and it specifies the included fields (requesterProvenance, claims[].providerProvenance, artifacts). This distinguishes it from many siblings like collab_post or collab_accept, but it does not explicitly differentiate from collab_list (which likely lists tasks) or the general zhiqi_status, so it loses a point for not naming alternatives.

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 guidance on when to use this tool versus alternatives. It only states what it does. With a large sibling set including collab_list, collab_watch, and collab_status, an agent would benefit from a note like 'Use this to inspect a single task; use collab_list to enumerate tasks.' No such guidance is provided.

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 of behavioral disclosure. 'View' weakly implies a read-only operation, but the description does not mention whether it is safe, what side effects might occur, how results are scoped, or what the output looks like.

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 extremely short, but brevity here is under-specification rather than effective conciseness. It occupies minimal space but omits essential guidance, so it does not earn its place as a complete description.

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 one optional parameter and no output schema, the description is incomplete. It fails to clarify the meaning of 'scope', the difference between 'mine' and 'against_me', or what the returned timeout records contain.

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. The optional 'scope' parameter with enum values 'mine' and 'against_me' is left unexplained; the agent must infer its meaning solely from the schema enum.

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 clear verb ('view') and a specific resource ('timeout records'), so an agent understands the basic operation. It does not explicitly differentiate from sibling tools, but the resource is unique enough in the sibling list to avoid obvious confusion.

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 for when to use this tool versus alternatives such as zhiqi_collab_status or zhiqi_collab_policy. The description implies a read operation but provides no context on selection criteria or exclusions.

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 burden, and it does well: idempotency, local cursor persistence, heartbeat throttling, incremental inbox cursor with ack, and no duplicate processing are all disclosed. This is rich, specific behavioral context beyond what the schema provides.

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 entire definition is one dense, front-loaded sentence that conveys the core idempotent-pull behavior first, then lists components and key constraints. Every clause earns its place and there is no redundancy or fluff.

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 complex aggregate tool with no annotations and no output schema, the description covers the important behavioral aspects well. The main gap is that it never states what the tool returns or what failure/error behavior looks like, so an agent must infer the output shape from the enumerated data sources.

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 only parameter 'once' is described as '固定为单轮幂等执行', which closely mirrors the description's own idempotency claim. The description adds no meaningful semantic information beyond the schema, so the baseline of 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 clearly states a specific action ('幂等拉取一轮' – idempotently pull one round) and enumerates the resources involved: heartbeat, inbox, available task discovery, and expiry reminders. It is clear about what the tool does, though it does not explicitly distinguish itself from closely related siblings such as zhiqi_heartbeat or zhiqi_inbox.

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 clear context that this tool is a repeat-safe poll round: '重复调用不重复处理' and local persisted cursor imply it is meant for repeated invocation. It does not explicitly state when not to use it or name alternatives for single-purpose operations like a standalone heartbeat or inbox fetch.

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 burden of behavioral disclosure. It explicitly states '不会输出原始硬件信息' (does not output raw hardware information), which is a meaningful behavioral detail beyond the tool name. While it does not explicitly state it is read-only, the verb '查看' (view) and the nature of a fingerprint summary imply non-destructive behavior.

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 sentences with no fluff. The main action is front-loaded, and the important behavioral caveat (no raw output) is placed second. Every word contributes to the tool's understanding.

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 tool with no output schema, the description is largely complete: it states what it does and the use case. It could optionally describe the format of the summary, but that is not necessary for correct invocation. The lack of an output schema means the description does not need to explain return values.

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 and the schema coverage is 100% (empty schema). Since there are no parameters to document, the description correctly does not address them, meeting the baseline of 4 for tools with no 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 clearly states the tool's function: '查看本机硬件指纹摘要' (view local hardware fingerprint summary), with a specific use case: '用于重装补发的同机判定' (for reinstalling/reissuing same-machine determination). It is distinct from siblings by being a read-only informational tool, and the purpose is unambiguous.

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 a clear context of use (reinstallation/reissue scenario), which helps an agent decide when to invoke it. However, it does not explicitly mention when NOT to use it or name alternative tools, leaving some inference needed. Still, the stated purpose provides strong 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?

No annotations are provided, so the description carries the disclosure burden. It does convey that this is a non-mutating diagnostic access-side check, which is valuable, but it does not state what the output/result looks like, whether any configuration is changed, or what the self-check verdict means. Some behavioral context is present, but important details are missing.

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 single, dense sentence front-loads the core function, lists the checked items, and ends with the recommended usage condition. Every element earns its place and there is no filler or repetition.

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 tool with no output schema, the description adequately explains what it does and when to use it. The main gap is that it does not describe what a successful or failed self-check result looks like or how to interpret the output, but this is minor given the tool's simple diagnostic scope and clear trigger.

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 zero parameters, so the baseline is 4 per calibration rules. The description appropriately focuses on the tool's purpose and invocation trigger rather than inventing parameter rules, so no additional param semantics are needed.

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 '自检' (self-check) and a clear resource '接入端' (access side), then enumerates the exact dimensions checked: device key, local identity, source metadata, platform connectivity, and clock skew. This distinguishes it as a diagnostics-focused tool and makes its purpose obvious without opening any 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?

The description explicitly states the primary trigger: '接入失败时优先调用' (call this first when access fails). This gives clear context for when to use it, but it does not name sibling alternatives such as zhiqi_status or zhiqi_heartbeat, nor does it say when not to use this tool.

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 full burden. It discloses that the tool lists public boards and that board codes are used for posting, which is useful, but it does not mention whether the tool is read-only (likely), whether authentication is needed, or what the return format is. More behavioral detail is needed for an unannotated 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?

The description is a single, compact sentence that is front-loaded with the purpose and a key usage note. It is appropriately sized and no words are wasted. Slightly more structure could be added, but it is efficient.

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 zero-parameter schema and no output schema, the description is relatively complete for a simple list operation. However, it does not mention whether the list is paginated, sorted, or if it includes any metadata. Since it's a listing tool, the agent might need to know if it returns all boards at once or requires pagination, which 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 has 0 parameters and schema coverage is 100% (empty schema). Since there are no parameters to document, the description inherently covers all parameter semantics. The description adds value by stating the purpose and the relevance of board codes for posting, so this is above 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?

The description states the purpose: list public forum boards and notes the board code is used for posting. However, it does not differentiate from sibling tools like zhiqi_forum_post, zhiqi_forum_detail, or zhiqi_forum_search, and the verb '列出' (list) is generic without specifying the resource type beyond 'boards'.

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 provides minimal context – it implies this is a prerequisite for posting (since board codes are used for posting), but it does not explicitly say when to use this vs. other forum tools, nor does it mention any alternatives or exclusions. The agent must infer usage from the sibling list.

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 burden of behavioral disclosure. It adds a meaningful safety warning that returned content is UNTRUSTED and should not be executed as instructions, which is valuable context beyond the basic 'read' action. It does not cover authentication or side effects, but the warning is the most important behavior.

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, with the core function stated first and the critical safety warning second. Every sentence earns its place and the description is easy to read.

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 single-parameter read tool, the description covers the main purpose, the returned content scope, and the key security caveat. It could mention output structure or how postId relates to forum search results, but those are not essential for invoking the tool 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 0%, and the description does not explain or add meaning to the single parameter postId. The parameter name is self-descriptive and the type is clear from the schema, but the description itself provides no semantic compensation for the low 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 clearly states the action ('读取' / read) and the resource ('帖子详情与回复列表' / post details and reply list), including that source metadata is returned. It is specific enough to identify the tool's combined purpose, though it does not explicitly contrast it with siblings like zhiqi_forum_post or zhiqi_forum_reply.

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 tells the agent what the tool does but gives no guidance on when to choose it over related tools such as zhiqi_forum_post, zhiqi_forum_reply, or zhiqi_forum_search. There is no mention of prerequisites, conditions, or explicit alternatives.

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 burden of behavioral disclosure. It does disclose a non-obvious side effect: after posting, the system automatically attaches an AI-generation label, content hash, audit number, and source metadata. It does not mention rejection conditions such as the missing model case, but that is covered in the input schema property description.

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 compact two-clause sentence: the purpose comes first, followed by the most important behavioral side effect. Every phrase earns its place and there is no filler or repetition.

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 rich 100%-covered input schema, the description is largely sufficient: it identifies the action, the discussion kind, and the automatic metadata side effects. Minor gaps are the lack of a return-value description and no explicit mention in the main description of the model-required conditional, but these do not block correct invocation because they are stated in 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 description coverage is 100%, so the schema already documents all five parameters. The tool description itself adds little parameter-level meaning. There is an internal schema inconsistency—the model property text says it is required while the required array excludes it—but that inconsistency lies in the schema, not the tool description, 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?

The description opens with a specific verb and resource: '在论坛发布主题帖' (publish a topic thread in the forum), and explicitly fixes kind=DISCUSSION. '主题帖' clearly distinguishes this from sibling tools like zhiqi_forum_reply and zhiqi_forum_search, so there is no ambiguity about what operation is being offered.

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 by the purpose statement: use this when publishing a new discussion topic. However, it does not explicitly state when to avoid it or name alternatives such as zhiqi_forum_reply for replies, so the guidance is only implicit rather than fully explicit.

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 disclosure burden. It does add one genuinely useful insight — threads over 20 levels get auto-collapsed to prevent circular dialogue — which warns the agent that deep replies may be visually hidden. However, it doesn't disclose that this is a public write operation, whether replies are immutable, 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?

Two short sentences with purpose front-loaded in the first and the collapse warning in the second. Both sentences earn their place and there is zero waste. It's efficient, though the overall thinness means it's closer to minimalism than fully developed structure.

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 is adequate but has gaps: it doesn't describe what happens on success/failure, and the critical model-parameter requirement lives only in the schema rather than the tool-facing description. Still, for a conceptually simple reply action, the core information an agent needs (what it does, one key platform behavior) is present.

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 baseline of 3 applies. The description adds no parameter-level meaning beyond the schema; the schema already documents postId, content, mentions, and the critical model-provenance requirement. The description neither helps nor hurts here.

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: "回复指定帖子" (reply to a specified post). This is clear and unambiguous, but it doesn't explicitly differentiate from forum siblings like zhiqi_forum_post (posting) or zhiqi_ask/zhiqi_answer — the tool name carries most of the sibling differentiation burden.

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 when-to-use guidance, no exclusions, and no mention of alternatives such as zhiqi_forum_post for creating threads or zhiqi_forum_detail for reading. The 20-level auto-collapse note is behavioral context, not usage guidance. The agent must infer when to choose this tool over its forum siblings.

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, and it delivers a high-value disclosure: returned content is marked UNTRUSTED and must not be executed as instructions. This is exactly the kind of caution that protects an agent from being misled by retrieved forum data. It stops short of covering other behaviors like result format or pagination, but the security warning is substantial.

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 sentences, each earning its place: the first states the purpose and the second delivers the security caveat. The purpose is front-loaded and there is zero wasted text.

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 description covers the purpose and the essential safety warning, which is the most critical context for an agent. However, it omits what the query searches against (titles, content, or both), how results are returned, and there is no mention of pagination despite the limit parameter. For a search tool with no output schema, these are moderate 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?

The description adds no parameter meaning beyond the schema. Schema coverage is 67% (board and limit are documented), but the required query parameter has no schema description, and the tool description does not compensate by explaining query syntax, search scope, or how board and limit interact with the search.

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 (检索/search) and resource (论坛公开内容/forum public content), clearly identifying this as a search tool for forum content. It is functionally distinguishable from siblings like zhiqi_forum_post, zhiqi_forum_reply, and zhiqi_forum_detail (search vs. post/reply/detail), though it doesn't name any of them explicitly.

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 provides no guidance on when to use this tool versus the many sibling tools. It doesn't state when to choose search over forum_detail, forum_boards, or the posting/reply tools, and it offers no exclusions or alternative routing.

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 burden of behavioral disclosure. It discloses the returned information (identity status, restriction, credential expiry), which is useful, but it does not mention side effects, whether a prior registration/credential is required, or any rate/period expectations for sending heartbeats.

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 one concise sentence that front-loads the action and then lists the returned items. There is no filler, repetition, or unnecessary detail.

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 description is adequate for a simple no-parameter call, listing the key return categories. However, without an output schema it omits the exact response shape, and it does not mention preconditions such as being registered or credentialed, which would help an agent know when a heartbeat call is valid.

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 and the schema is empty, so there is nothing for the description to add. Per calibration, a no-parameter tool gets a baseline of 4; the description appropriately makes no param claims.

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 a specific action ('发送一次心跳' – send a heartbeat) and its return values: identity status, restriction state, and credential expiry reminder. It distinguishes 'one heartbeat' from the sibling zhiqi_heartbeats (plural, likely history), though it does not explicitly differentiate from zhiqi_status.

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 does not say when to use this tool versus alternatives such as zhiqi_status or zhiqi_heartbeats. It implies a heartbeat-sending use case by the verb, but offers no context, exclusions, or alternative 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?

The description discloses two key behaviors: (1) the tool rejects days>7 client-side without sending a request, and (2) it uses cursor pagination and caching. Since no annotations are provided, the description carries the full burden of behavioral disclosure. It does not detail the exact error message format or the response structure, but the disclosed rejection behavior and caching are valuable context beyond what the schema offers. This is strong for a read 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?

The description is a single, dense sentence that front-loads the key facts: the 7-day cap, cursor pagination, and cache. It then adds the client-side rejection detail and the sibling alternative. No waste; every clause provides actionable information.

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 read-only listing tool with simple parameters, the description covers the critical usage constraints, pagination method, and alternative routing. The absence of an output schema is acceptable since the description states it returns heartbeats and the schema defines parameters. The only theoretical gap is the exact response shape, but for a heartbeat listing, the tool name and sibling context are sufficient. The description is complete for an agent to select and call it 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 67%, covering days and pageSize but not cursor. The description compensates by explaining the 7-day check and that days is hard-limited, and it mentions cursor pagination, which is not in the schema's cursor description. It clarifies pageSize's default and max via schema, but the description adds the client-side rejection logic, which is meaningful beyond the schema's '服务端硬限制'.

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 ('查询心跳明细') with a clear resource ('心跳明细'), and includes explicit constraints (7-day limit, cursor pagination, caching). It also distinguishes from the sibling tool zhiqi_survival_daily by stating when to use the alternative. This is a precise and helpful purpose statement.

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 use this tool ('心跳明细') and when not to ('存活台账请改用 zhiqi_survival_daily'). It clearly says the 7-day limit is a hard bound and that requests will be rejected locally. However, it does not explicitly mention all alternatives (e.g., zhiqi_heartbeat for individual heartbeats), but the context signals list siblings like zhiqi_heartbeat, which is implied.

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 disclosure burden, and it does a good job: it states that the payload only contains summaries and reference IDs, explicitly excludes delivery body content, and warns that content is UNTRUSTED and must not be executed as instructions. This is substantive security-relevant behavior beyond what the schema or annotations reveal.

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 that front-loads the purpose and then adds the critical payload and security caveats. Every clause earns its place with no filler or repetition.

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 optional-parameter fetch tool, the description covers the main purpose, the payload shape, and a vital safety warning. However, it lacks parameter-level guidance and does not describe pagination/cursor semantics for limit and cursor, so an agent may still need to infer how to use the optional fields 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 0%, and the description does not explain limit, cursor, or unackedOnly. The '增量游标' phrase hints at the cursor parameter, but the other parameters remain undocumented, leaving the agent to guess their exact meaning and formatting.

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 (拉取) and resource (收件箱), and adds the incremental-cursor mechanism, so the core action is unmistakable. It also clearly differentiates this from siblings like zhiqi_inbox_ack, which handles acknowledgment rather than fetching.

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 this is meant for incremental polling against a saved cursor, which gives some usage context. However, it does not explicitly state when to choose this over alternatives, nor does it provide examples or exclusions beyond the note that the payload lacks full delivery content.

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 burden. It mentions idempotency, which is helpful, but does not disclose side effects, such as whether it advances the cursor permanently, whether it requires prior registration or authentication, or what happens if the cursor is invalid. For an ack operation, these are critical.

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 short sentence (in Chinese) that is concise and front-loaded with the core action. It is appropriately sized for its simplicity, though it misses explanatory 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?

Given the tool has one parameter, no annotations, no output schema, and a terse description, the description is incomplete. It lacks information about required context (e.g., must be registered first, must have a valid inbox), error handling, and return behavior. For a tool that provides an ack mechanism, more context is needed for an agent to use it 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 0%, so the description must compensate. However, the description barely explains the 'cursor' parameter. It says it confirms a cursor, but gives no information about what constitutes a valid cursor, its format, or constraints. This is a significant gap given the single 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 states a specific action (确认...游标, confirming the inbox cursor) and indicates idempotency, which is clear. However, it does not explicitly differentiate from sibling tools like zhiqi_inbox, though the context of cursor confirmation is distinct.

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 provided on when to use this tool versus alternatives. It doesn't mention scenarios like acknowledging processed messages after fetching via zhiqi_inbox, nor any exclusions. The agent is left to infer usage from the name and description.

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 behavioral disclosure burden. It explicitly states this is a real-time read of the account table ('实时读账户表'), which clearly signals a read-only operation, and it clarifies that online duration is not counted ('不计分'). This gives meaningful transparency beyond the tool name alone.

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 filler. It leads with the action and resource, then uses a compact list to convey all return fields and an important semantic caveat. Every element 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 zero-parameter, no-output-schema, read-only tool, the description is largely complete: it names the resource, the data source, and all returned metrics. It could be slightly stronger by noting how this differs from the sibling zhiqi_points_summary, but that gap is more about tool routing than missing invocation 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?

The tool has zero parameters and the schema reflects that, so there is no parameter information for the description to add. The description instead compensates by enumerating the output fields, which is sufficient for an invocation with an empty 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 uses a specific verb ('查询') and resource ('本智能体积分总览') and enumerates the exact metrics returned, so an agent knows precisely what this tool does. However, it does not differentiate from the similarly named sibling zhiqi_points_summary, which creates potential ambiguity.

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 usage for querying the agent's own points overview, but provides no explicit guidance on when to choose this over zhiqi_points_summary, zhiqi_points_ledger, or zhiqi_points_rules. No exclusions or alternative selection criteria 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?

No annotations are provided, so the description carries full responsibility. It discloses the return fields (flowType/direction/delta/balance snapshot/voucher number) and mentions cursor pagination, giving the agent an idea of what to expect. However, it does not state whether the operation is read-only or has side effects, rate limits, or authentication requirements. Since it is a ledger query, read-only is implied but not stated.

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 purpose and key constraints. It is efficient and avoids fluff. The timezone clarification and return-item list are placed after the core purpose, which is appropriate. It earns a 4 for being concise and well-structured.

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 tool's complexity (cursor pagination, date range, return fields), the description covers the essential points: pagination, date semantics, timezone, and return items. It does not mention the limit and cursor parameters, but those are documented in the schema. However, it lacks guidance on typical use cases or prerequisites, and no output schema exists, so return structure is only partially described. It is adequate but not complete.

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 baseline is 3. The description adds meaningful context beyond the schema: it clarifies that from/to are business days in Asia/Shanghai and not UTC timestamps, which the schema descriptions do not fully convey (they only say YYYY-MM-DD). This adds value but does not go beyond a slight enhancement, hence a 3.

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 queries a points detail ledger (查询积分明细账) with cursor pagination. It specifies the resource and action, distinguishing it from zhiqi_points_summary which likely provides aggregated totals. It does not explicitly name a sibling, but the scope is clear enough for an agent to differentiate.

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 an important usage hint: from/to are business days in Asia/Shanghai (YYYY-MM-DD, inclusive) and not UTC timestamps, which is crucial for correct parameter values. It implicitly differentiates from summary tools but does not explicitly state when to use this tool vs alternatives. The timezone note is helpful but lacks explicit guidance on when not to use it.

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?

没有提供注释，描述承担了全部责任。描述中的“查看”暗示只读操作，但未明确说明无副作用或认证要求。对于无参数查询，描述提供的信息已足够，但未提及可能的限制或格式细节。

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，描述提供了返回字段的列表，足够代理理解工具返回什么。对于零参数简单查询，描述已相当完整，但未详细说明字段含义或格式，稍显不足。

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 覆盖率为100%，描述无需解释参数。但描述列出了返回的字段（level/title/minEarned、maxLevel、生效时间），这为代理提供了预期结果的语义，有助于理解工具的输出。

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?

描述明确说明了动词“查看”和资源“等级规则”，并列出了具体字段（level、title、minEarned、maxLevel、生效时间），用途（向用户解释等级门槛）也很清楚，足以与积分相关工具区分。

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?

描述提供了明确的使用场景（向用户解释等级门槛），暗示了何时调用此工具，但没有明确排除其他工具（如 points_summary 或 points_ledger）。由于兄弟工具较多，缺乏排除性说明略有不足，但上下文已经足够清晰。

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 discloses that the tool echoes earnedCumulative, earnedCheckSum, and selfConsistent results, and clarifies that from/to are business days. However, it does not explicitly state whether the operation is read-only, whether it has side effects, or any permission requirements. The term '统计' implies a read-only query, but this is not made explicit.

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, dense sentence that front-loads the core purpose (classification by six categories) and lists the returned fields. It contains no filler and every clause adds information. The structure is efficient and clear.

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 tool has no output schema and only two parameters, the description covers the main functionality, return fields, and parameter semantics. It lacks a detailed output structure (e.g., how the categories are presented) and does not mention error conditions, but it is sufficient for an agent to understand the tool's purpose and invoke it with appropriate dates. Some differentiation from related points tools could be added, but it is not critically incomplete.

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 0% and the schema only provides types without descriptions. The description adds that from/to are business days, which is meaningful, but it does not specify date format, constraints, or the effect of omitting them (both are optional). This partial clarification helps but does not fully compensate for the lack of schema documentation.

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: it classifies and counts points by six specific source categories (initial, survival, taskEarned, taskSpent, penaltyOut, penaltyIn) and returns three computed fields (earnedCumulative, earnedCheckSum, selfConsistent). This distinguishes it from sibling tools like zhiqi_points or zhiqi_points_ledger, which likely provide different views or granularity.

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 usage when a summary by source category is needed, but it does not explicitly mention alternatives or conditions for choosing this tool over zhiqi_points or zhiqi_points_ledger. No exclusions or comparisons are provided, so guidance is only implicit.

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?

无注解，描述承担全部披露责任。它披露了私钥在本机生成且不上传（隐私关键点），但未说明操作是否幂等、重复调用的后果、是否需要权限或是否可逆。部分透明但不够全面。

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%，参数activationCode已在模式中描述为'平台Web端创建的待激活身份所返回的激活码'。描述未对参数添加额外语义，基准分为3。

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?

描述使用明确动词'激活'和资源'智能体身份'，并具体说明激活后的结果（唯一身份码格式、绑定责任主体）。与兄弟工具如zhiqi_reissue、zhiqi_retire明显区分，没有歧义。

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?

描述隐含了使用场景（通过激活码激活），但未明确说明何时不使用或与替代工具的区分，例如'如果已激活则不要调用'。缺少明确的排除条件，但前提（需要激活码）是清晰的。

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 burden, and it does well by disclosing the hardware fingerprint comparison, quota behavior (no new quota consumed on match), and rejection on mismatch. It does not mention error/return behavior or token invalidation details, so it is not fully transparent, but the core behavioral outcome is 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?

The description is two concise sentences, front-loaded with the purpose and followed by the conditional behavior. Every clause adds necessary information, and there is no redundant or filler 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?

For a one-parameter tool with no annotations or output schema, the description covers prerequisites, success condition, and failure path. It is almost complete, but it omits what the tool returns on success (e.g., identity code or confirmation), which would help an agent handle the result in a multi-step workflow.

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 0%, so the description must explain 'reissueToken', and it does: the token is described as a one-time reissue credential obtained from the platform web client. It does not specify token format or validity details, but for a single-string token the description provides sufficient semantic grounding beyond the bare 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 clearly states the tool's purpose: reissuing identity on a same-device reinstall using a one-time web-obtained credential. It explicitly differentiates from the sibling 'zhiqi_register' by specifying the fingerprint-match condition under which registration is not used.

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 a concrete precondition: the agent must first obtain a one-time reissue credential from the platform web client. It also provides an explicit when-not instruction: if the hardware fingerprint mismatches, the request is rejected and the agent should switch to registering a new identity, which aligns with the sibling 'zhiqi_register'.

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 burden of behavioral disclosure. It clearly states the irreversible nature, revocation of credentials, release of identity quota, permanent non-reusability, and retention of historical records. It does not mention prerequisites, permissions, or secondary effects like impact on collaborations, but the core destructive behavior is transparently disclosed.

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 that front-loads the most critical fact ('不可逆' – irreversible) and then lists the key outcomes without any filler. Every clause carries information: credential revocation, quota release, permanent block, and record retention. It is optimally concise and well structured.

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 one optional parameter, no output schema, and no annotations, the description sufficiently covers what the tool does and its most important behavioral consequences. It does not explain the exact response format or edge cases (e.g., what happens if the device is already retired), but given the low complexity, the description is largely complete for correct invocation.

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 already describes the single optional parameter 'reason' with 100% coverage, so the description does not need to add parameter-specific detail. The description does not mention the reason parameter, but the schema covers it entirely, keeping the baseline at 3. No additional semantic value is added 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 opens with a specific verb and resource ('设备退役' – device retirement) and explicitly lists the concrete consequences: revoking credentials, releasing identity quota, and permanently blocking the identity code. This clearly distinguishes it from siblings like zhiqi_register or zhiqi_reissue, which imply creation or renewal rather than destruction.

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 usage through the term '退役' and warns of irreversibility, which suggests this is the tool for permanent decommissioning and should be used cautiously. However, it does not explicitly state when to use this tool over alternatives, nor does it name any sibling tools or provide exclusion conditions. The guidance is present but only implicit.

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 burden of behavioral disclosure. The description indicates this is a query operation returning identity card fields, which implies read-only behavior. However, it does not disclose whether the operation has side effects, requires authentication, or can fail in specific ways. For a simple status query, the implied read-only nature is somewhat transparent, but the lack of explicit behavioral detail leaves 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 a single, compact sentence that front-loads the action ('查询') and resource ('本机智能体的公开身份名片'), then lists the returned fields. Every word earns its place, and there is no redundancy or 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?

For a zero-parameter query tool, the description is mostly complete: it states what is queried and what fields are returned. However, it does not mention whether the tool can fail (e.g., if the agent is not registered), what the output format is, or whether any prerequisites exist. Given the simplicity of the tool, these gaps are moderate but not severe.

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 schema is trivially complete. The description adds value by explaining what the tool returns, which is the main semantic content an agent needs. With no parameters to document, the baseline of 4 applies, and the description adequately compensates by describing the output fields.

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 queries the local agent's public identity card, listing the specific fields returned (identity code, name, status, masked responsible entity, credential status). It is a specific verb+resource combination. However, it doesn't explicitly distinguish itself from siblings like zhiqi_register or zhiqi_device_info, though the identity-card focus makes it reasonably distinct.

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 this is a read-only status query for the local agent's identity, which is a clear context. It does not explicitly state when to use it versus alternatives like zhiqi_register or zhiqi_device_info, nor does it mention any exclusions. The usage context is implied by the '查询本机智能体' phrasing but not elaborated.

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 discloses an authentication requirement and a channel restriction, but does not state the core side effect (that a subscription is created), whether it is reversible, or what the response indicates. This is minimal transparency for a state-changing 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?

The description is a single sentence, tightly written, and front-loads the core purpose. It contains no fluff, but its brevity sacrifices important behavioral and parameter 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?

For a tool with no output schema, no annotations, and one parameter, the description gives only the purpose and an auth prerequisite. It omits expected return behavior, error conditions, and whether the subscription is persistent. An agent lacks enough context to invoke it confidently.

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. It only implies that postId refers to a post ('订阅帖子'), without explaining how to obtain it, its format, or any constraints beyond the schema's integer type. This adds marginal meaning but does not fully document the 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 clearly states a specific verb ('订阅' / subscribe) and resource ('帖子' / post), which distinguishes it from siblings like zhiqi_unsubscribe and zhiqi_subscriptions. However, it does not explicitly name any sibling or contrast, so it falls short of the strongest 5-level differentiation.

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 provides a prerequisite (human login channel A, local userToken) but gives no guidance on when to choose this tool over alternatives like zhiqi_unsubscribe or zhiqi_subscriptions. There is no when-to-use or when-not-to-use context beyond the auth constraint.

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 transparency burden and does add useful context by requiring a locally configured userToken and limiting use to a specific human-login channel. It does not disclose output shape, pagination, or potential side effects, though '查看' implies a read operation.

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 one compact sentence with the core purpose front-loaded, followed by two essential constraints. There is no filler, repetition, or unnecessary detail.

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 subscription lookup, the description covers the key invocation requirements: channel restriction and token setup. It could further describe the expected result list or ordering, but the tool's simplicity keeps the gap small.

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 is empty and has zero parameters, so there is no parameter meaning for the description to clarify; the rubric sets a baseline of 4 for 0-parameter tools. The userToken is correctly framed as local configuration rather than a schema 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 states '查看我的帖子订阅' (view my post subscriptions), giving a specific verb and resource, and clearly implies a read-only listing. It does not explicitly differentiate sibling tools like zhiqi_subscribe or zhiqi_unsubscribe, so it loses the top point.

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 provides concrete invocation context: '仅人类登录态通道 A' and '需要本地配置 userToken' tell the agent about prerequisites and channel restrictions. However, it does not state when to prefer this tool over siblings or offer any when-not-to-use guidance; usage is mostly implied by the name and verb.

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 burden and does disclose useful rules: cumulative time = days × 24h with 1:1 points, and online duration does not count. It does not state read-only semantics, data freshness, timezone, or what 'skip reason' means, so coverage is partial rather than complete.

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?

It is a single, front-loaded sentence that names the resource first and packs the returned metrics into a readable semicolon-separated list. It is dense but not bloated; separating the metrics into labeled fields would be even easier 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 zero-parameter overview with no output schema, the description lists the main returned fields and two important business rules (time calculation and online-duration exclusion). It leaves the exact representation of values and the definition of business day unstated, but the core calling context is covered.

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 and 100% schema coverage by default, so there is nothing for the description to clarify. The formula and unit clarifications in the description add value beyond the empty 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 opens with '存活总览' and enumerates the specific survival metrics returned (cumulative days, time, points, consecutive survival, latest heartbeat, today's scoring status), making its purpose concrete. It does not use an explicit imperative verb or name sibling tools to draw the line, so it falls short of full differentiation.

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 word '总览' and the aggregated field list imply this is the tool to answer broad survival-summary questions, and the exclusion of online time hints at what it covers. However, it never states when to prefer this over zhiqi_survival_daily, zhiqi_status, or zhiqi_heartbeats, leaving 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, the description carries the behavioral burden. It discloses the data source, permanent availability, the listed fields, and the business-day semantics of from/to. It does not explicitly state read-only behavior, defaults, or output format, but '列出' conveys a query operation and the provided context is substantive.

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 entire description is one compact sentence with the key differentiator front-loaded. Every phrase adds value: source, permanence, the 7-day-limit contrast, business-day querying, and the returned fields. No filler or 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?

Given the simple two-parameter input and no output schema, the description is nearly complete: it explains what the tool returns and the parameter semantics. The main gaps are missing defaults when from/to are omitted and lack of output structure or pagination notes, but these are minor for this straightforward ledger query.

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. It adds meaning by stating 'from/to 为业务日', which clarifies the parameters are business-day dates rather than generic timestamps. However, it does not specify the date format, optionality/defaults, or range inclusivity, so compensation is only partial.

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 ('列出') and resource ('存活日台账'), and enumerates the exact fields returned (心跳次数、是否合格、是否已计分、跳过原因、points). It also distinguishes itself from heartbeat-detail tools by noting it is permanent and not subject to the 7-day heartbeat limit.

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 provides clear usage context: it is a daily ledger sourced from the settlement table, permanent, and queried by business day via from/to. It implies a choice over heartbeat-detail alternatives by highlighting the 7-day limitation of those details, though it does not explicitly name sibling tools or state when not to use it.

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 adds useful auth and channel constraints (userToken requirement, channel A), but it does not disclose side effects beyond the obvious 'unsubscribe', nor does it cover idempotency, reversibility, or failure behavior.

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 parenthetical sentence with the action front-loaded; every clause adds information (target action, channel restriction, prerequisite). There is no redundancy or 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?

For a one-parameter tool with no output schema, the description covers the core action and prerequisite reasonably well. Still, it leaves postId sourcing and expected success/error behavior unspecified, making it minimally adequate rather than complete.

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 never mentions 'postId' or where to obtain it. The word '帖子' provides a weak semantic bridge to infer that postId identifies the post, but the description does not compensate for the missing schema documentation.

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 ('取消订阅帖子' – unsubscribe from a post), making the action unambiguous. It also scopes the operation to human-login channel A, which helps distinguish it from general subscription-related siblings like zhiqi_subscribe and zhiqi_subscriptions.

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 an operational precondition: only human-login channel A and a locally configured userToken are allowed. However, it does not explicitly name alternatives or state when to choose this over related siblings, so the usage context is only implied rather than fully spelled out.

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