独行录 / opcmenu

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

The description discloses substantial behavior beyond annotations: real conversation creation, sending openers in the user's name, non-guaranteed signup success, always returning signupVerificationRequired=true, no persistent deduplication key, and no concurrent dedupe guarantee. These are critical side-effect and idempotency warnings that annotations only hint at.

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 long but every sentence carries essential risk or workflow information. It is front-loaded with the core purpose and login requirement, then layers mode-specific behavior, verification steps, and failure caveats without 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 complex, non-idempotent, side-effect-heavy tool with no output schema, the description covers login requirements, return-field meaning, external form completion, timeout handling, and deduplication behavior. It leaves no critical operational question unanswered.

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 compensates well for opener by explaining that omitting it sends a platform-prewritten opener after authorization. arrangementId's meaning is implied through 'accept get_my_dispatch's suggestion' but not explicitly defined, leaving a small semantic gap.

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: accepting the suggestion from get_my_dispatch, and clarifies the two concrete actions MEET and ATTEND. It clearly distinguishes this tool from the sibling decline_dispatch_arrangement by stating what acceptance initiates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit routing: use get_signup_activity to verify signup status, list_my_signups to check delivery, and submit_signup only when materials are missing. It also instructs not to auto-resend after unclear results or timeouts, providing strong when-to-use and when-not-to-use 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 adds valuable behavioral context beyond annotations: it notes that login is required and that other profile fields are left untouched. These details complement the annotations (readOnlyHint=false, destructiveHint=false) without contradicting them. It could mention duplicate behavior, but this is not a major 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 compact and well-structured: the login requirement is front-loaded, the core action is stated in one sentence, and the example is short and illustrative. No filler or redundant explanation.

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 mutation with a rich schema and annotations, the description is mostly complete. It covers login, scope, non-destructive behavior, defaults, and gives an example. It does not describe the return value or error cases, but that is not essential given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by providing an example mapping a user request to type/url/visibility, and by restating the visibility default. This adds practical semantics that help an agent infer correct parameter values.

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: '给当前用户加一条链接' (add a link for the current user), with a specific verb and resource. '不动其它字段' also distinguishes it from update/removal operations, and it is clearly differentiated from sibling tools like remove_profile_link and set_link_visibility.

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 context: login is required, the operation targets the current user's links, and the example demonstrates how to map a natural-language request to parameters. It does not explicitly name alternatives or when-not-to-use conditions, but the context is clear enough.

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 the login requirement, the mutual DM restriction, the automatic unfollow side effect, and idempotent behavior. This adds meaningful behavioral detail beyond the annotations, which already indicate idempotency and non-destructiveness.

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 well-structured, with the key login requirement first, followed by effects, use case, and idempotency. Every sentence adds useful information without 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 single-parameter action with strong annotations, the description is complete enough for an agent to call it correctly. It covers the main side effects, the intended scenario, and the idempotency guarantee, which is all the context needed here.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is only one parameter and the schema covers it fully with a clear description. The tool description does not add extra parameter-level detail, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: block a user, and specifies the concrete effects: mutual DM restriction and automatic unfollow. It is specific and goes well beyond restating the tool name, making the tool's purpose 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?

It provides a clear usage context: use when dealing with harassment. However, it does not explicitly mention alternatives or exclusions, such as when to prefer report_content or unfollow_creator instead.

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?

Adds far beyond the annotations: login requirement, preview mode that does not persist, mandatory user confirmation before execution, silent ignoring of invalid IDs with diff fields, empty-string rejection on reviewNote, 200-id cap, and the guarantee that only application results are changed and delivery status is untouched. None of this contradicts the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but structured with clear sections (需要登录, 何时用, 组合链, 口径/坑). It is front-loaded with the trigger condition and the single most important fact (login). Every sentence carries operational value, including the note about why preview exists and the diff return.

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?

Covers preconditions, workflow, return diff fields, limits, and what the tool does not touch. No output schema exists, so the description does well to explain requested/updated/ignoredIds. However, it doesn't describe the full response shape or error behavior, which would be useful for a complex mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all parameters. The description adds meaningful behavior for preview (no write, returns candidate list for confirmation), reviewNote (empty string rejected, omitted = no change), and reinforces the 200-id limit. This extra context is valuable but the schema does the baseline heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (bulk update reviewStatus), resource (signup submissions), and scope (batch operations like 'make all AI ones shortlisted, rest waiting'). It clearly differentiates from the 200-checkbox web UI and implies the batch nature. No ambiguity about what the tool does.

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?

Explicitly says when to call it: when the user voices a batch operation such as '把做 AI 的都入围、其余候补'. It also provides a composition chain with list_signup_submissions and preview=true/false. It doesn't explicitly name the single-submission alternative (review_signup_submission) or say 'use that for one-off changes', so exactly when-not is implied rather than stated.

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?

注解已声明 destructiveHint=true，描述额外补充了“需要登录”的权限前提和“已取消/已结束不可再取消”的状态约束，为代理提供了注解之外的行为信息。描述与注解一致，不存在矛盾。

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?

参数 activityId 在 schema 中已有完整描述（“活动 id”），schema 覆盖率为 100%，描述没有为参数增加额外语义。按高覆盖率基线评为 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?

描述使用明确动词“取消（下线）”和资源“我发起的某个活动”，准确表达了操作对象与范围。与同族的 cancel_need、unpublish_need、update_activity 等工具在语义上可清楚区分，不会让代理产生混淆。

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?

明确给出登录前提，并说明“已取消/已结束的活动不能再取消”这一使用限制，帮助代理避免无效调用。但没有显式指出何时应改用 update_activity 等替代工具，因此未达到最高分。

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

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

Beyond the annotations (destructiveHint=true, readOnlyHint=false, idempotentHint=true), the description adds key behavioral context: login is required, only the initiator can cancel, the operation is irreversible, and specific 403/409 failure cases are enumerated. This is strong disclosure for a destructive action.

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 well-structured: the critical terminal/irreversible nature and login requirement are front-loaded, the alternative tool is clearly named, and failure semantics are separated in a concise block. Every sentence 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 single required parameter, no output schema, and annotations already covering mutation/destruction, the description covers everything an agent needs: prerequisites, ownership restriction, irreversibility, alternatives, and error expectations. Nothing important 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 coverage is 100% and the only parameter, needId, is already documented as '需求 id'. The description implies it must be the caller's own need, which adds a small semantic constraint, but it does not add substantial parameter-level detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: the initiator cancels their own need, and it clarifies this is a terminal state that cannot be reopened or edited. It also explicitly differentiates from unpublish_need, so the purpose is unambiguous even among many siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit when-to-use rule (canceling permanently) and a when-not-to-use rule with the alternative (temporarily hiding should use reversible unpublish_need). It also provides concrete failure semantics for common misuses, leaving little to inference.

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

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

Annotations already mark this as read-only, idempotent, and non-destructive, and the description adds meaningful behavior beyond that: login is required, the response has ok/via/reason semantics, and it explains each failure reason and its real-world meaning. Since there is no output schema, this behavioral documentation is essential and well done.

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 long but tightly organized with clear headers and bolded key terms. Every section—eligibility rails, failure reasons, remediation paths, and when to call—carries operational value, and the primary purpose 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?

Given the complexity (two eligibility paths, multiple failure reasons, no output schema), the description fully equips an agent: it documents the response contract, explains the most common failure case, names the only remediation tool, and explicitly warns that agent-side cannot complete the organizer profile flow. Nothing critical 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 zero parameters and the schema coverage is 100%, so there is nothing for the description to add about parameters. Per the baseline for parameter-less tools, a 4 is appropriate because the description instead focuses on response semantics and usage 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 opens with a precise verb+resource statement: checks whether the current user meets the prerequisites for initiating an activity. It goes further by naming the two eligibility rails (owner vs organizer) and the via field semantics, which makes it easy to distinguish from any sibling tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly instructs to call this before create_organizer_activity ('发起活动（create_organizer_activity）前先用它，免得白填'). It also says when not to attempt remediation: missing organizer data cannot be fixed with any available write tool, and it steers the agent away from trying other 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?

The description discloses critical behavioral traits beyond the annotations: the operation is irreversible, it transfers all products and conversations, and failure returns ok=false with specific reasons such as invalid_token, not_found, already_claimed, or self. The irreversibility warning adds meaningful context without contradicting destructiveHint=false, since the operation transfers rather than destroys data.

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 well-structured: a lead sentence states the action, a second sentence explains token provenance, and a note block covers irreversibility, sibling differentiation, and failure modes. Every sentence adds information with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description covers preconditions, input provenance, effect scope, irreversibility, alternative tools, and failure semantics. This is complete enough for an agent to invoke the tool correctly and interpret likely failure responses.

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 covers both parameters at 100%, and the description adds valuable provenance details: token maps to ?ct=<token> in the email link, while creatorId maps to /u/<creatorId> and refers to a pre-recorded placeholder creator account. This helps the agent correctly populate the 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?

States a specific verb and resource: using an email token to transfer all products and conversations from a placeholder creator account to the current account. It explicitly distinguishes itself from claim_product, so an agent can tell this is a whole-account claim rather than a single-product claim.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear usage context: login is required, the token comes from a cold-start outreach email link, and the intended alternative is claim_product for single-product claim codes. This explicitly routes the agent to the right tool for the right scope.

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

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

Annotations already establish readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds genuinely new behavioral context beyond those annotations: the login requirement, the post-then-review model (先过后审), and the consequential side effect that claiming immediately publishes the product. No contradiction with the annotations exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single compact sentence that front-loads the login prerequisite, then states the action, the immediate-publish consequence, and the code source. Every clause earns its place and nothing repeats what the schema or annotations already provide.

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 auth prerequisite, target resource type, the side effect of immediate publication, and code provenance. It omits failure behavior (e.g., invalid or already-used codes), which is a minor gap given the tool's simple surface area.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the sole claimCode parameter is already described as 认领码. The description adds only marginal value beyond the schema by noting that the code is generally issued by admins, which documents provenance but not format, validation, or failure 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?

The description states a specific verb (认领/claim), resource (a product pre-recorded by admin or crawler), and mechanism (claim code) that binds the product to the current account. It is clearly about products and claim codes, but it does not explicitly contrast with the close sibling claim_creator_by_token, leaving sibling differentiation implicit rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description conveys clear usage context: login is required, the claim code is generally issued by an admin, and the target product is pre-recorded rather than user-created. It does not provide explicit when-not guidance or name alternatives such as claim_creator_by_token or create_product, so exclusions are left to inference.

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

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

描述超越了 annotations 的内容，明确说明这是真实状态变更、非幂等、双方确认后才完成，并解释了等待确认状态（authorDoneAt / claimerDoneAt）以及各类失败语义。与 readOnlyHint=false、idempotentHint=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?

描述按【需要登录】【前置】【失败语义】分段组织，信息密度高且无冗余。前置条件和双人确认逻辑放在前面，错误码放在后面，结构清晰。

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?

该工具是包含双方确认状态机和多种失败场景的变更操作，且无 output 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?

input schema 已对参数有 100% 覆盖，描述进一步补充了 conversationId 必须来自 contact_need 建立的会话，并间接说明 needId 与 conversationId 的绑定关系，增强了参数含义。

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?

明确表述了操作：在接洽会话中确认完成需求，并说明双人确认机制（发起人和承接人各调一次）后置为 COMPLETED。与 cancel_need、delete_need、reopen_need 等兄弟工具语义区分清楚。

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?

给出了明确的使用前提：conversationId 必须是 contact_need 建立的会话，且需要双方各确认一次；还提示调用前先向用户确认事情确实办完。虽然未显式说明与其他工具的对比或排除场景，但语境和前置条件已经足够指导使用。

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

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

Beyond annotations, the description discloses required login, the fact that this is a real state change, the specific error onboarding_incomplete, and the expected preflight sequence. This is exactly the behavioral context an agent needs beyond readOnlyHint/destructiveHint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short labeled sections: requirement/purpose, preconditions, and caution. The most important operational detail (login, state change) is front-loaded, and every sentence carries actionable information with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter state-transition tool with no output schema, the description covers authentication, prerequisites, failure mode, required preflight check, and user confirmation. Nothing essential for correct invocation 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 zero parameters and schema coverage is 100%, so there are no parameter semantics to clarify. The description appropriately focuses on preconditions and side effects instead, matching the baseline for a parameterless tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description states a specific verb and resource: 把入驻引导标记为完成, with the concrete outcome of stamping onboardedAt. It is clearly distinguishable from the sibling get_onboarding_status, which retrieves the same state rather than mutating it.

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?

Description gives explicit preconditions (persona required; FOUNDER needs at least one product and a filled bio) and tells the agent to call get_onboarding_status first and confirm with the user before proceeding. It does not explicitly discuss alternatives or when-not-to-use, but the context is unambiguous.

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

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

Annotations already state idempotentHint=true, but the description goes further by detailing idempotency semantics ('重复调用只返回已有会话'), login requirement, 'anyone can contact, no upper limit', and precise failure codes including 429 chat_quota_exhausted. The description also matches annotations and adds valuable operational 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 well-structured into clear sections: core behavior, composition chain, and failure semantics. Each sentence earns its place, and the most important action and login notice are front-loaded. No filler or redundancy is present.

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 parameter and no output schema, the description covers return value (conversationId), follow-up tool calls, prerequisites, idempotency, and all relevant error cases. It provides everything an agent needs to invoke the tool correctly and handle 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 coverage is 100% and the single parameter needId is already described as the need id sourced from list_needs_feed / search_needs / get_need. The description references the target need but does not add new parameter-level semantics, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 对某条需求「找他聊聊」：与发起人建立 1-1 会话并登记接洽. It clearly states what the tool does and differentiates it from related tools like complete_need by explaining the inviting behavior and that the need will not be taken offline.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit workflow guidance: returns conversationId, then use send_message to continue, optionally get_conversation_needs beforehand, and complete_need after delivery. It also explains quota failure semantics and tells the agent not to retry on 429. This is strong, actionable routing guidance beyond mere context.

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

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

Beyond the annotations, the description discloses that login is required, that the goal is persistent, that there is no persistent request dedup key, and that the agent should query the current state rather than auto-retry after a timeout. This is especially valuable since idempotentHint=false alone does not convey the concrete retry behavior needed to avoid duplicate goals.

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 every sentence carries operational value: creation semantics, timeout handling, and a pre-creation check plus downstream id usage. It is front-loaded with the core purpose and contains no filler or redundant restatements of the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a create tool with no output schema, the description covers essential operational needs: auth requirement, duplicate avoidance via get_my_work, non-idempotency handling, and the returned id's use in subsequent tools. However, the lack of parameter semantics for title and intent means an agent still has to guess at their exact meaning, preventing a perfect score.

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% — title and intent have no descriptions in the schema. The tool description adds no parameter-level meaning; it never explains what 'title' or 'intent' should contain or how they relate to the goal. Given the low coverage, this is a clear gap.

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: '创建一个持久的独行录合作目标' (create a persistent collaboration goal) and clarifies that '用户成为发起人' (the user becomes the initiator). This clearly distinguishes the tool from siblings like create_collaboration_task by naming a distinct resource and describing its key semantic.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit instructions on when to use this tool: '先 get_my_work 核对已有目标，再创建' (first check existing goals via get_my_work, then create), and how to handle uncertain outcomes: '结果不明或超时后先查询现值，不要自动重发'. It does not explicitly contrast with create_collaboration_task, but the preconditions and follow-up id usage imply a well-defined workflow.

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 goes well beyond annotations by disclosing login requirements, notification side effects, collaborator authorization constraints, non-idempotency with no dedup key, and the recommended verification workflow. These are substantive behavioral facts that annotations alone do not convey, and nothing contradicts the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well-structured, front-loading the core action and login requirement before important caveats. Every sentence carries meaningful guidance about authorization, idempotency, notifications, or verification, with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a side-effecting, non-idempotent creation tool with no output schema, the description covers the most important operational concerns: authorization, notification, timeout handling, and verification via get_collaboration_goal. It does not explicitly describe the success return value, but its verification guidance effectively compensates for that 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 only 20%, so the description must compensate. It does clarify assigneeId semantics (omitted means self, must be a goal collaborator if specified), but it does not explain title, detail, or goalId meaning beyond obvious inference, and dueAt semantics are left to the schema. That is partial compensation for a low-coverage 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 and resource: creating a task within a collaboration goal, and it explicitly covers assignment behavior when assigneeId is provided. This distinguishes it from siblings like create_collaboration_goal and update_collaboration_task, since it is clearly about task creation/assignment rather than goal creation or task modification.

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 usage context: call only after the user authorizes assigning to a collaborator, use get_collaboration_goal to verify before/after creation, and do not auto-retry on timeout or unclear results. It does not explicitly mention update_collaboration_task as the alternative for changing an existing task, so it stops short of a full when-not-to-use statement.

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

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

在 annotations 只提供 readOnlyHint/idempotentHint 等布尔提示的情况下，描述额外披露了需要登录、先过后审的异步风控、slug 全局唯一及 slug_taken 错误、description 影响内容质量。这些是调用方做决策和预期管理的重要行为信息，且与 idempotentHint=true 一致，无矛盾。

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?

对于无 output schema 的创建类工具，描述覆盖了登录要求、幂等 upsert、唯一性错误、审核机制和后续动作，已经相当完整；唯一缺口是没有说明成功后的返回内容，但这个缺失不严重影响工具选择与调用。

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 对 9 个参数覆盖 100%，已承担主要说明责任；描述额外补充了 slug 的全局唯一性与冲突错误，以及 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?

明确说出“为当前用户创建一人公司主页”，动词+资源+归属都清楚；还补充“已存在则等价于更新”“每个用户最多一家”，把 create 工具的实际 upsert 行为讲明，能与其他 get/list 类公司工具区分开。

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?

给出了明确使用场景：当前用户、最多一家、已存在则更新，并指示“建到了就可以在引导里 complete_onboarding”。虽然没有点名替换工具 update_my_company，但“已存在则等价于更新”已经隐含了覆盖更新场景的路由语义。

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

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

Annotations only say readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds substantial behavioral context: publishing is public, appears immediately in the feed, undergoes background async moderation, triggers automatic vector matching and push to managers, and requires user confirmation before posting. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is organized into clear labeled sections (【需要登录】【写好它】【挂载】), front-loads the core behavior, includes useful examples, and every sentence adds practical guidance. It is moderately long but appropriate for the tool's complexity and the behavioral caveats.

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?

Covers login, async review, public visibility, auto-matching, parameter-writing guidance, user confirmation, context mounting, and image prerequisite. It does not describe the API response or created-need identifier, and does not explicitly warn about duplicate creation, but given no output schema and the descriptive richness elsewhere, the coverage is strong.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds real value: title must be 3–120 characters and clearly state the need; detail specificity improves matching and search; contextType+contextId must be passed as a pair; images should be mirrored via upload_image_from_url. It doesn't explain the type enum, but the schema already does thoroughly.

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?

Description states a clear verb and resource: '以当前用户身份发布一条需求' (publish a need as the current user), and frames it as the starting point of the need-exchange core loop. It explicitly distinguishes the follow-up action by naming get_need_recommendations as a separate tool for viewing matches.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear when-to-use context: login required, publish immediately visible, no need to wait for review, and async risk control. It also points to get_need_recommendations as a follow-up alternative and tells agents to pre-upload images via upload_image_from_url. It does not explicitly say 'use update_need instead of creating a duplicate', but the create-vs-modify boundary is reasonably 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?

Annotations only say the tool writes (readOnlyHint=false) and is not idempotent, but the description adds far more: login requirement, post-create feed visibility semantics (先过后审, no gray release), error codes with remediation routes (organizer_profile_required / profile_incomplete / no_published_product), dedup semantics (same clientRequestId or title within 5 min returns the existing activity with deduped=true), and the deliberate absence of an agent-side organizer-name write path (SMS-gated subtree). No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Long but fully earned for a 23-parameter creation entry point: it is organized into labeled sections (需要登录/何时用/组合链/口径·坑) with numbered pitfalls and bold key terms, and the decision-relevant content (when to call, chain position) is front-loaded. No filler sentences; even the COMPETITION reminder that echoes the schema functions as a trap warning rather than duplication.

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 write tool with no output schema, the description nearly suffices: it covers prerequisites, error handling, dedup, auth, and the post-create workflow. The return contract is only implied via the chain (slug → signupPageUrl, deduped=true) rather than spelled out, and the 'exits 里写了各自怎么补' reference presumes external documentation not present here. Minor gaps against an otherwise comprehensive definition.

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 still adds genuine meaning: the baseline four-question set that lands when extraQuestions is omitted (and the warning not to hand-build dozens of fields), the 'all extra questions are optional' rule, the organizerName fallback chain with its SMS-verification constraint, and the 5-minute dedup window for clientRequestId. This exceeds baseline by explaining cross-parameter behavior and rationale the schema 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 states a concrete trigger ('用户说「帮我发一场分享会 / 建一个报名」时调它') and names the exact resource scope (活动本体 + 报名配置一次写入). It declares itself the '唯一正确入口' for in-site activity creation, explicitly distinguishing it from updates (update_activity) and downstream read/management tools. An agent can pick this tool over the ~130 siblings 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?

Gives the exact user utterances that should trigger the call, plus an explicit exclusion: activity body changes go through update_activity. The 【组合链】 section lays out the entire lifecycle (create → get slug/signupPageUrl → read → reconfigure → review submissions → export), so it is unambiguous where this tool sits versus siblings like list_signup_feed, bulk_review_signup_submissions, or issue_signup_export_link.

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

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

Annotations show readOnlyHint=false, destructiveHint=false, but the description adds valuable context: it requires login ('【需要登录】'), it's a post-hoc review flow ('先过后审'), and the result is immediately published and visible. It also discloses slug auto-generation and collision handling. This exceeds the annotation baseline meaningfully.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, all dense with information: login requirement, publication status, review flow, slug behavior, and forward pointer to update_my_product. No redundant phrasing. The call to action and routing are 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?

Given 9 parameters and no output schema, the description explains the critical creation semantics: immediate visibility, review flow, slug generation/collision, and next-step tool. It doesn't mention output/response, but the tool is a creation action where the created product ID might be expected; however, the description is still sufficient for an agent to select and invoke the tool correctly. Slight gap: no mention that name/tagline are required, though the schema handles that.

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 44%, so the description must compensate. It specifically adds meaning for the most important derived behavior: slug optional/auto-generation with derived suffix when occupied. It also states that name is used for URL generation, and that update_my_product handles links/media/tags, guiding whether to pass those params now. However, many params (cat e.g., description, links, tags) are not explained in the description, relying on 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: '新建一个产品 / 作品，先过后审：创建后立即发布对外可见' — a specific verb (create) + resource (product/work) with a clear behavioral outcome (publish immediately, visible externally). It also distinguishes itself from sibling tools by noting that update_my_product is for subsequent edits. The title 发布新产品 reinforces the action.

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 states when to use it (to create a new product) and explicitly routes the agent to update_my_product for continuing to add links/media/tags. It also explains slug behavior. However, it doesn't explicitly describe when NOT to use it versus claim_product or follow_product, though the distinction is reasonably clear.

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

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

The annotations already mark the operation as destructive, non-idempotent, and open-world, and the description adds substantial context beyond that: login is required, the tool may call platform LLM/backend scheduling/notifications, there is no persistent deduplication key, and uncertain or timed-out results should be checked before reattempting. This is rich, non-redundant behavioral disclosure and does not contradict the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every sentence earns its place: auth requirement, core action, reason semantics, side effects, retry policy, and verification path. It is front-loaded with the primary purpose and then logically layered with caveats. No filler or redundant restatement of the tool name.

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 side-effect complexity, no output schema, and open-world/idempotent-false annotations, the description is remarkably complete. It tells the agent what the tool does, what each reason means, what side effects may occur, how to handle uncertainty or timeout, and how to verify the resulting state. The agent has enough information to invoke the tool correctly and recover from ambiguous 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 0%, so the description carries the burden of explaining parameters. It does valuable work by defining the nuanced reason enum (SWAP, WRONG_DIRECTION/OTHER, HAVE_ALREADY/NOT_NOW) with concrete effects. arrangementId and note are left to their self-explanatory names and schema constraints, which is a minor gap but not a serious one.

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 ('拒绝' reject) applied to a clear resource ('尚未接受的建议' not-yet-accepted suggestions), and it distinguishes this tool from acceptance or dispatch-related siblings by explaining the reason-code outcomes. It is not a tautology and gives the agent enough to know what operation is performed.

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 maps each reason code to a behavioral outcome: SWAP means change to another, WRONG_DIRECTION/OTHER may reschedule, HAVE_ALREADY/NOT_NOW skip the step. It also tells the agent to verify with get_my_dispatch and not auto-retry. It does not explicitly name accept_dispatch_arrangement as the alternative, but the contextual routing is otherwise clear.

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

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

Annotations already convey destructive, non-read-only, and idempotent behavior. The description adds the login requirement and explicitly explains the no-op behavior when no rating exists, which complements the idempotentHint annotation. No contradictions with annotations are present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single compact sentence with no filler. It front-loads the login requirement, then states the action, scope, and idempotency behavior, making every part informative.

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 delete operation with rich annotations covering destructive and idempotent behavior, the description is complete. It includes authentication needs, target scope, and the no-op edge case, so an agent has all necessary context to invoke 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 100%, so both targetType and targetId are already documented. The description clarifies that the target can be a product, park, or manager, which aligns with the enum, but adds little beyond what the schema provides. Baseline 3 is appropriate given full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('删除' delete) and a specific resource ('当前用户对某对象的评价' the current user's rating for a target). It clearly distinguishes this from sibling tools like rate_product, which creates a rating, and delete_need, which deletes a need rather than a rating.

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 states that login is required and that the operation is idempotent, which gives clear context for when to call it. It does not explicitly name alternative tools or exclusion cases, but the context is sufficient for an agent to understand this is the deletion counterpart to rating operations.

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

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

Beyond the destructiveHint annotation, the description discloses that the operation is irreversible, cascades to all contact records, requires login, and returns 403 not_your_need for non-owners. It also explicitly frames the tool as a hard delete rather than a reversible action, adding meaningful behavioral context not present in the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured, front-loading the critical hard-delete and irreversibility facts, then providing routing guidance, and ending with failure semantics. Every sentence carries useful information with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter destructive tool with no output schema, the description covers all essential context: authentication, irreversibility, cascade behavior, preferred alternatives, user confirmation, and error semantics. Nothing an agent needs to safely invoke this tool 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 input schema has 100% description coverage for the single needId parameter, so the schema already explains the parameter. The description adds ownership context ('自己的需求') but does not need to explain the parameter format further; 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 states a specific verb and resource: '硬删除自己的需求' (hard delete one's own need), with explicit scope ('自己的需求') and consequences ('连同全部接洽记录，不可恢复'). It also distinguishes itself from siblings cancel_need and unpublish_need, so an agent can reliably tell them apart.

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 says when to use this tool versus alternatives: '日常收尾优先用 cancel_need（保留记录）或 unpublish_need（可逆下架）', and reserves delete for cases where the data should truly be erased. It also instructs the agent to confirm with the user before calling, which is clear operational guidance.

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

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true), the description discloses login requirements, the one-record-per-pair constraint, and the important upsert behavior that calling again edits the existing endorsement. It also adds business rules around self-endorsement, unclaimed accounts, and mutual blocks that annotations cannot express.

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 dense sentence front-loads the login requirement, then states the operation, parameter essentials, target exclusions, and create-or-edit behavior. No filler or redundant restatement of the tool name exists.

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 three-parameter tool with no output schema, the definition covers auth, required/optional fields, invalid target cases, and edit-on-recall semantics. With schema covering parameter formats and annotations covering read-only/destructive flags, nothing essential for correct invocation 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 coverage is 100%, so the baseline is 3. The description adds value beyond the schema by constraining userId semantics: the target cannot be the caller, cannot be an unclaimed placeholder, and the operation is blocked under mutual block. It also clarifies the relation parameter is optional and body is required text, though the schema already encodes body minLength and relation optionality.

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: writing a recommendation testimonial for a specific 主理人. It also distinguishes from siblings by noting '无星级' (no star rating), separating it from rate_product, and by describing the create-or-edit behavior that get_creator_endorsements would not cover.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear when-to-use context and explicit when-not constraints: cannot write for yourself, cannot write for an unclaimed placeholder, and cannot write when mutually blocked. However, it does not name alternative tools or explicitly route the agent to a read-only sibling for viewing endorsements, so it stops short of full 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?

描述在注解之外补充了关键行为：需要登录、互相关注成为好友、好友可见链接的可见性变化、以及幂等重复关注无效果。这些副作用和前置条件不是注解能直接推导出来的，对代理正确评估调用后果非常有价值。

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 的简单关注操作，描述已覆盖登录条件、参数来源、幂等性、好友关系效果和可见性变化。注解也补充了 idempotentHint 和 destructiveHint，整体信息完整，没有明显缺失。

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 对 userId 的描述已覆盖 100%，基线为 3。描述额外说明“先用 list_creators / get_creator 拿 id”，为代理提供了获取该参数的实用路径，这超出了 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?

描述明确说明具体动作是“关注某位主理人（用户 id）”，并进一步解释互相关注会成为好友、好友可见链接会对你可见。这清楚地将 follow_creator 与 follow_product、unfollow_creator 等同类工具区分开，动词和对象都具体无歧义。

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?

描述给出了明确的使用上下文：需要登录后才能关注，并建议先用 list_creators / get_creator 获取目标用户 id。虽然没有逐一说明何时不应使用本工具，但已提供足够的前置条件和操作路径，AI 能据此正确触发或引导用户。

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?

Even though annotations already include idempotentHint=true and readOnlyHint=false, the description adds valuable behavioral context: repeated following is a no-op, only published products can be followed, missing/unpublished products return 404, the follow is unilateral with no notification to the other party, and it does not count as a greeting. This goes well beyond annotation defaults and discloses important side effects and error 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 structured into clear labeled sections: login requirement, when to use, combination chain, and edge cases. Although dense, every sentence carries operational value and there is no filler or repetition of annotation data.

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 single-parameter mutation tool with no output schema, the description covers login requirements, usage triggers, alternative tools, the full workflow, error conditions, idempotency, and side effects. Nothing that an agent needs to correctly invoke this tool 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 input schema already fully documents productId as a cuid obtained from get_product/search_products, so the baseline is 3. The description adds list_service_products as another source and embeds productId in a concrete workflow, which is modest additional value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states exactly what the tool does in the first line: it follows/saves a product. It explicitly distinguishes itself from follow_creator by clarifying this tool is for products, not people, and notes that follow_creator affects friend relationships and 'friend-visible' links. This is a specific verb+resource with strong sibling 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?

It gives concrete trigger phrases ('我先存着 / 关注一下 / 回头再看'), clearly states when NOT to use it (following a person → use follow_creator), and provides a full combination chain: obtain productId from search_products, list_service_products, or get_product → follow → view via get_my_card. This is explicit usage guidance with no ambiguity.

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

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

Annotations declare readOnly/openWorld/idempotent/not destructive, and the description adds behavior beyond them: slug takes priority over id, only one of the two params is expected, and the signup field determines whether in-platform signup is possible. It also exposes the related deep link and edge cases.

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 core purpose is front-loaded, and the signup routing is organized as a scannable list. No sentence is filler: the type warning and the 'only one chain' note each address a real failure mode.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description supplies the return-value scope (title, description, time/location, organizer, signup status) and covers the main edge cases an agent will encounter. The tool definition is effectively self-contained 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 only defines id and slug; the description adds the critical constraint '两个参数二选一，slug 优先'. This tells the agent that one parameter is needed and which to prefer when both are supplied, which is not inferable from 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-resource pair ('按 id 或 slug 拿活动详情') and lists the returned fields. It also distinguishes the tool from get_signup_activity by stating that signup-specific actions belong to that sibling. The title '查活动详情' is consistent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides an explicit decision tree: if signup is non-empty, use get_signup_activity and submit_signup; if empty and externalUrl exists, direct the user to externalUrl; if both are empty, there is no signup entry. It also warns not to rely on the type field, which prevents a common misrouting.

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 traits absent from annotations: it requires login, costs money because members are LLM-pair-reviewed and cached, metadataOnly skips member judgment, warming indicates background processing, supply has three distinct empty states, and pagination needs profileVersion. These enrich the sparse annotations (readOnlyHint=false, openWorldHint=true) without contradicting them.

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 long but tightly organized with clear headers (何时用 / 组合链·多跳 / 口径/坑) and bulleted pitfalls. Every section carries load-bearing operational guidance, and the purpose is front-loaded before the details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by explaining the response shape: ego-centric rings with members, myAnchors, anchor.placed, members[].id/claimed, supply values, warming flag, and profileVersion cursor. It also covers the main follow-up tools and edge cases, leaving little ambiguity for an agent.

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 descriptions already cover all three parameters with 100% coverage, including the default-fallback behavior and metadataOnly semantics. The description adds workflow context (recursive expansion, cost implications) but no new parameter-level meaning, so 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 names a specific verb and resource: it returns an ego-centric supply-chain view anchored at a node ('返回以某个节点为锚的自我中心视图'), and lists concrete user questions it answers. It also differentiates itself by naming sibling tools like list_chain_group_members and set_my_chain_position for follow-up actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

A dedicated 【何时用】 section states the exact questions this tool answers, and the workflow guidance explicitly tells when to use metadataOnly=true to probe before switching to list_chain_group_members to inspect members. It also gives exclusions: don't iterate to the end, don't re-call the same anchor, and don't start conversations with unclaimed members.

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

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

Beyond annotations, the description discloses authentication needs, server-side permission checks, the closed-task filtering behavior, the 200-row cap, the reachingLimit truncation signal, and the idempotent backfill of periodic iterations on read. This adds substantial behavioral context without contradicting the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and information-dense. Every sentence contributes a distinct fact: purpose, login/permission, filtering and limits, idempotent side effect, and routing to sibling tools. There is 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?

Even without an output schema, the description enumerates what is returned (goal details, permissions, collaborators, tasks), covers auth and permission checks, explains edge-case behavior (truncation, closed tasks, backfill), and points to sibling tools for related mutations. This is sufficiently complete for an agent to invoke 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 description coverage is 0%, so the description must carry weight. It provides strong semantics for includeClosed (closed tasks, max 200, reachingLimit truncation), but goalId is only implied as the target goal, not explicitly documented. Since goalId is the sole required parameter, this is a partial gap.

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 views goal details, permissions, collaborators, and tasks ('看独行录目标详情、我的权限、合作人、任务'). It uses a specific verb and resource, and the mention of create_collaboration_task and update_collaboration_goal helps distinguish it from mutation siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states the login and member-permission requirement, explains includeClosed=true behavior and the 200-item limit, and routes the agent to create_collaboration_task for creating tasks and update_collaboration_goal for initiator edits. This gives clear when-to-use and when-to-use-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?

Annotations already signal read-only and idempotent behavior, and the description adds meaningful context beyond that: only PUBLISHED companies are returned for the public, owners can see their own non-published companies, and a not-found result returns found=false. This gives the agent a clear behavioral contract even without an output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: core function first, then when-to-use guidance, then a resource link. Each section earns its place and adds distinct value without 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 single-parameter read tool, the description covers the lookup mechanism, visibility rules, owner exception, and not-found behavior. With no output schema, the found=false note helps fill the return-value gap. Nothing critical is missing 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?

Schema coverage is 100%, and the slug parameter already has a description ('公司主页 slug（URL 上 /c/<slug>）'). The tool description adds no new parameter semantics beyond restating that lookup is by slug, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('按 slug 获取某个一人公司主页') and clarifies the public/owner visibility distinction. It differentiates itself from sibling tools like get_my_company and list_companies by scoping to a single company by slug with PUBLISHED-only behavior.

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 '【何时用】' section gives clear context: use it when the user wants to see what a specific one-person company does. It does not explicitly name alternatives or exclusion cases, but the visibility rules ('仅返回已发布 PUBLISHED 的公司；本人 owner 可见自己任意状态的公司') imply when it applies and when it might not.

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

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

Annotations already convey readOnlyHint, idempotentHint, openWorldHint, and non-destructiveness. The description adds meaningful context beyond those: login is required, and the semantics of exchange/myContacts/canRequest are explained including the ACCEPTED visibility condition. It could add output format or error details, but for a simple read tool this is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tightly organized sections: first the purpose and return-field semantics, then the actionable combination chain. Every sentence adds value, and the most important constraints are 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 single-parameter read-only tool with no output schema, the description covers the essential context: login requirement, input constraint, output field meanings, and downstream action routing. Nothing needed to invoke it correctly 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 sole parameter conversationId is already fully documented in the schema as the 1-1 conversation id. The description reinforces the 1-1 constraint but adds no extra parameter syntax or format details. High schema coverage keeps this at the baseline of 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 names a precise operation: view the contact-exchange state of a specific 1-1 conversation. It clearly distinguishes this read query from siblings like request_contact_exchange and respond_contact_exchange by describing its read-only scope and the three state fields it returns.

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?

Explicitly states the login requirement and 1-1 conversation constraint, then gives a concrete combination chain: canRequest=true routes to request_contact_exchange, inbound PENDING routes to respond_contact_exchange, and empty myContacts routes to add_profile_link first. This is strong when-to-use and 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?

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: authentication is required, the user can only access their own conversations, and message contents are not returned here since '读消息用 read_messages'.

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 dense sentences front-load the auth requirement and operation, list returned fields, state the access scope, and give a routing pointer. Every sentence earns its place with zero 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 simple single-parameter read-only getter, the description covers auth, access scope, returned fields, and alternative routing. Even without an output schema, an agent knows what to expect and when to choose a different tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema fully documents the single conversationId parameter, so the baseline is 3. The description adds the important semantic constraint that the ID must refer to a conversation the current user participates in, which is not captured in the schema 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 resource ('返回...某个会话的详情') and enumerates the returned fields (members, linked products, recent preview, read position, mute). It also scopes the operation to conversations the current user participates in and explicitly redirects message reading to read_messages, distinguishing it from that sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the login prerequisite, the access precondition ('只能查自己参与的会话'), and explicitly names read_messages as the tool to use when the goal is reading messages. This provides concrete when-to-use and when-not-to-use guidance, though it does not compare against list_my_conversations or get_conversation_needs.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, and the description states 需要登录, which is beyond what annotations provide. It also discloses boundary behavior (conversationNeed=null when unbound, peerOpenNeeds capped at 10). It does not detail pagination or ordering of peerOpenNeeds, which prevents a 5, but the combination of auth note + null case + cap is strong.

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 dense but well-structured: a headline result, a bullet-like enumeration of payloads, a null case, a chain, and a scope restriction. Every sentence earns its place and the critical usage context 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 read-only tool with one fully documented parameter and no output schema, the description covers the main usage context, auth requirement, return highlights, and integration with send_message/complete_need. Missing an explicit note that the response contains both fields even when peerOpenNeeds is empty, and no details about sorting, but these are minor given the richness already 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 coverage is 100%, so the schema fully documents conversationId; the description reinforces that it is the id from list_my_conversations and implies it must be a conversation the user participates in. That adds a validity condition beyond the schema's one-line field 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 names a specific verb ('查'), a precise resource ('会话的需求上下文'), and immediately enumerates the two return payloads (conversationNeed and peerOpenNeeds) with their relevant fields. It also contrasts with siblings like get_conversation and list_my_conversations by stating exactly what layered context it adds.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit combination chain: list_my_conversations → this tool → send_message / complete_need, tells conditions (only own conversations), and says what to use it for ('判断能否/是否该 complete_need', '找合作切入点'). It also preempts misuse by noting it cannot query other people's conversations.

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

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

注释已声明 readOnlyHint、idempotentHint、destructiveHint，说明这是安全只读操作。描述额外补充了返回内容包含 profile 和已发布作品列表，且按热度和发布时间排序，这对调用后的预期有实质帮助。

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?

描述精简，核心功能前置，随后用【何时用】【相关 resource】分段补充，没有任何冗余信息，每句话都有用途。

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?

这是一个单参数只读查询工具，描述涵盖了功能、使用时机、返回内容、排序方式和相关 deep link，虽然没有 output 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%，id 已有“用户 id（cuid）”的说明。描述只重复“按 id”，没有提供超出 schema 的额外语义，符合高覆盖场景下的基线 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?

动词明确（按 id 查），资源明确（主理人 profile + 已发布作品列表），并附排序规则。与 list_creators、get_creator_endorsements 等兄弟工具在内容上足以区分，不是泛泛的“查询”描述。

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?

【何时用】明确给出了使用场景：“用户想了解某位主理人在做什么、关注他/她的全部作品”。但没有说明何时不该用或给出替代工具的对比，因此未达到 5 分标准。

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

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

Annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false) already cover the safety profile, and the description adds genuinely valuable behavioral context beyond them: response contents (text + relation, no star, total count, myRating when logged in) and the critical data-sparsity caveat that empty returns are normal rather than an error. This prevents an agent from misinterpreting empty results as a failure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short labeled sections front-load the core return value first, then usage guidance, then calibration context. The 口径 section is the longest but earns its place because it carries the unique data-sparsity warning; no sentence is pure 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 read-only call with one required param and a fully documented schema, the main completion risk is response interpretation. The description partially compensates for the missing output schema by naming the response fields (text, relation, total, myRating) and flagging empty returns as the norm, though it stops short of a precise response shape or pagination details.

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% — userId, sort (enum with Chinese descriptions), limit (with default), and cursor are all documented in the input schema. The description adds little per-parameter meaning beyond that; its extra details (no star rating, myRating) are response semantics rather than parameter semantics. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: '返回某主理人收到的推荐口碑' and specifies the exact return shape (text + relation, no star rating, plus total count), with myRating when logged in. This clearly distinguishes it from sibling read tools like get_creator (works list) and from the write tool endorse_creator.

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 【何时用】 section states the intended scenario explicitly — person due diligence ('谁背书过 TA、以什么关系、说了什么'). It also provides a when-not-to-use signal (endorsements are nearly nonexistent site-wide, so get_creator's works list is more reliable for judging someone) and explicitly names endorse_creator for the write path.

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 openly explains behavior beyond the annotations: it is not purely read-only because the positioning path may trigger a background LLM re-judgment and write back, matching readOnlyHint=false. It also discloses failure degradation to null, the meaning of degraded[], and why null ≠ 0, along with rate-limit safeguards ensuring repeated calls are safe.

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?

Although long, the description is densely structured with clear sections (when to use, combination chains, pitfalls/scope) and every sentence carries actionable information. It front-loads purpose and uses explicit formatting to make the length navigable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description must compensate, and it does: it lists all six returned components, provides the exact field paths used in chains, explains degradation semantics, and covers the non-read-only cost guards. An agent has enough to call the tool and interpret the response 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?

With zero parameters, the schema leaves nothing to explain; the baseline is 4. The description adds no parameter detail but does enrich understanding of the response structure through field paths like unread, attention.top[].viewerId, deadlines[].slug, and chatQuota.remaining, which supports the separate return-value semantics.

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 is explicit and specific: it aggregates six named items scattered across six screens into one response for 'today' queries, naming each item (unread messages, recent viewers, chat quota, deadlines, top three actions, pending review counts). It also distinguishes itself from siblings like get_my_work and get_my_dispatch, making its purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states exactly when to start here ('any how is today / what needs handling / daily report' scenario') and gives explicit routing rules: use get_my_work for collaboration goals, get_my_dispatch for dispatch, get_my_invite when chatQuota.remaining=0, and get_my_positioning for the full task list. This is exemplary when-to-use vs 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?

Annotations already declare readOnly, openWorld, idempotent, and non-destructive hints. The description adds meaningful behavioral context beyond annotations: login is required, the tool returns grouped and visibility-tagged data, and the 'missing' field serves as a ready-made completeness checklist. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with labeled sections: content summary, when to use, combination chain, modification routing, and completeness semantics. Despite its length, every section adds practical value and the core promise is front-loaded in the first sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read-only aggregation tool with no output schema, the description fully covers what data is returned, when to use it, how to chain it with other tools, and where to go for modifications. Nothing essential is missing for an agent to invoke 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?

The tool has zero parameters and schema description coverage is 100%, so the description has no parameter burden. It correctly implies no inputs are needed and focuses on what the response contains.

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-resource relationship: one call retrieves the complete structured set of 'who I am' data, enumerating basic info, links with visibility, published products, role profiles, and followed products. It clearly differentiates from sibling getters by emphasizing aggregation ('一次调用拿全') and by naming alternative tools for modifications.

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 lists when to use this tool (writing openers, filling external forms, generating BP outlines, judging demand fit) and advises against chaining multiple tools for the same data. It also routes modifications to update_my_profile and set_my_role_profile, giving clear 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?

The description adds meaningful behavioral nuance beyond the annotations: it explains the opener=null case and that the effective message is the platform default, preventing the agent from misinterpreting null as an error. This is exactly the kind of context annotations cannot convey.

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 organized into clear labeled sections: when to use, combination chain, and pitfalls. Every sentence adds value, and the critical null/effective caveat is given dedicated space. It is concise despite covering several important aspects.

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 tool with no output schema, the description covers what the agent needs: when to call it, how it fits with sibling tools, and the key semantic trap (null vs effective). Nothing important 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 zero parameters, so the schema covers everything trivially. The description adds no parameter detail, but none is needed. Baseline 4 for no-parameter tools 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 identifies the tool as a read operation for the user's chat opener, with explicit use cases: '要改开场语之前先读现状' and answering what others see when contacting. It also implicitly differentiates from the sibling set_my_chat_opener by naming it in the combination chain.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use guidance: read before editing, and when users ask what others receive. It also gives a usage chain, telling the agent to use set_my_chat_opener after reading, and to read get_my_card/get_my_products before writing. This is clear and actionable.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, and the description adds valuable context: login requirement, included statuses, legacy PENDING_REVIEW semantics, null-return behavior, and uniqueness per user. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, front-loaded with the login requirement, and organized into what it does and when to use it. Every sentence adds information; no filler or redundant restatement of the schema or title.

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 tool with no output schema, the description covers authentication, return semantics, edge cases (null, archived, legacy pending review), and a concrete use case. An agent has enough to decide when to call it and what to expect.

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, so there are no parameter meanings to document. The baseline for zero-parameter tools is 4, and the description correctly relies on implicit current-user context instead of padding with parameter details.

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?

Description states a specific verb ('返回') and resource ('当前用户名下的一人公司主页'), and adds scope details: any status including ARCHIVED, PENDING_REVIEW as legacy-only, and company=null when not created. This differentiates it from siblings like get_company, update_my_company, and list_companies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear when-to-use guidance: read current fields, slug, and status before modifying company profile, plus the one-company-per-user invariant. It does not explicitly name alternatives or state when not to use it, so it stops short of full 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?

The description discloses the key side effect beyond annotations: calling this tool marks the current suggestion as seen and affects backend automatic replacement, explicitly stating '不是纯只读'. It also explains fillStatus semantics and that FAILED results are not automatically re-reported. This aligns with readOnlyHint=false and adds meaningful operational nuance.

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 but information-dense, front-loading the login requirement and scope, then covering side effects, state handling, and alternatives without wasted words. Semicolon-separated clauses keep related behaviors grouped and scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, no-output-schema tool, this description is remarkably complete: it states prerequisites, scope, side effects, retry semantics, and even cross-references the relevant sibling tools. An agent has enough context to decide when to call it and what to do with the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters and the input schema is empty, so the baseline is 4. The description adds no parameter-related confusion and even references fillStatus, which is a response/state field rather than an input parameter. No additional parameter documentation is 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 uses the specific verb '查看' and identifies the resource as dispatch arrangements, enumerating the exact categories it covers (paths, suggested contacts/activities, items awaiting feedback, and inbound requests). It also names accept_dispatch_arrangement and set_dispatch_outcome as the follow-up tools, making the boundary between viewing and acting explicit.

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: it requires login, is gated by a server-side gray release, and should be used for viewing rather than accepting or providing feedback—those are explicitly routed to sibling tools. It also advises on retry behavior for FILLING and how to treat FAILED results. However, it does not mention when to use decline/skip/report/respond_dispatch_inbound, so guidance is not exhaustive.

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 goes well beyond the annotations by disclosing the lazy generation of the referral code on first call, the login requirement, and that joined only exposes nickname/status without contact info. It also warns against rewriting the canned copy and explains shortLink vs link constraints, giving the agent critical operational 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 dense but well-structured with headed sections and front-loaded trigger conditions. Every block carries actionable guidance—copy constraints, message-length limits, stats semantics, and follow-up workflow—so no sentence feels like 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?

With no output schema present, the description compensates thoroughly by enumerating the returned fields and their business meaning. It covers the full end-to-end usage flow, including how to choose, personalize, deliver, and later verify referral outcomes, leaving no obvious gap for correct invocation and interpretation.

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?

This tool has zero parameters, so the baseline is 4; there is no input ambiguity to resolve. The description instead adds valuable output semantics—template labels, stats fields, and link selection—which is more than sufficient 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 clearly specifies what the tool returns: 5 SMS templates, 2 WeChat templates, an exclusive short link, and three-part stats (opens/registrations/onboarded). It anchors the purpose to concrete user intents like inviting friends or needing more opening quota, which separates it from siblings such as get_my_brief.

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 '何时用' section gives explicit trigger phrases and conditions. The '组合链' section prescribes the actual workflow: choose a template by label, send it from the user's phone, then check stats.onboarded later. It also explicitly redirects quota checks to get_my_brief or chatQuota, naming the alternative 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?

The description goes well beyond annotations by disclosing that this tool refreshes the positioning snapshot and writes PositioningState, so it is not a pure read tool and should not be called in a loop. It also explains level precedence (declared > inferred > observed), the monotonicity of task completion, the default omission of guides, and the instruction to rephrase LLM judgments rather than inventing levels. These are meaningful behavioral disclosures.

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 long but densely organized with clear sections: when to use, the agent-vs-App differentiation, a concrete tool mapping table, and pitfalls. It is front-loaded with the most important trigger phrases and alternative routing, and every section adds operational value.

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, the absence of an output schema, and the subtle side effects, the description covers everything an agent needs: what is returned, how to interpret levels, how to handle nextUp items, which sibling tools to call, what parameters are required together, and which tasks require manual verification via mark_positioning_task.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds valuable context: includeGuides=true must be paired with taskKey, only that one guide is returned, and all 39 guides are stripped by default to avoid tens of thousands of tokens per call. This is more actionable than the bare 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 states a specific verb and resource: it returns the current five-level main storyline position, six-dimension profile, title and total score, plus all task completion states and nextUp. It also names the user queries that should trigger this tool, which makes it easy to distinguish from get_my_brief and other getters.

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 guidance is explicit: it gives the exact user-phrase triggers, names get_my_brief as the lightweight alternative, and provides a detailed mapping from nextUp items to sibling tools like update_my_profile, set_my_role_profile, get_my_invite, create_need, create_product, set_my_chain_position, get_my_card, and list_my_conversations. It even tells the agent to execute the tasks rather than just read the 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?

注解已提供 readOnlyHint=true、idempotentHint=true、destructiveHint=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?

单句描述包含三项关键信息：登录要求、返回值、调用时机，且认证这一前置条件被前置标注。没有冗余文字，每部分都承载独立信息。

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?

工具无参数，按规则基准为 4。描述中的“当前用户”补充了身份解析语义——即工具基于登录会话确定目标对象，而非接受用户 ID 参数，这对代理理解调用方式有实际价值。

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

描述使用具体动词“返回”和明确资源“当前用户设置的兴趣标签”，清楚说明了工具的功能与范围，并点明数据用途是“回显”。这与众多 get_my_* 兄弟工具（如 get_my_profile、get_my_card）能自然区分开。

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?

“用于回显，改前先读”明确给出了使用时机：在修改偏好之前先读取当前值用于界面回显。虽然没有直接点名 set_my_preferences 这个写操作兄弟工具，但“改前先读”已隐含了读写配对的调用顺序，上下文清晰。

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 a login requirement ('需要登录') and clarifies that the result includes all product statuses and all links, adding behavioral context beyond the readOnly/idempotent annotations. It does not detail pagination or exact response shape, but that is a minor gap for a simple read-only list 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 compact and well-structured, with the core function stated first, followed by output scope and practical usage guidance. Every sentence adds value 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 read-only listing tool, the description covers the login requirement, the exact scope of results, and the intended use case of obtaining productId. Even without an output schema, an agent has enough information to select and invoke 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 an empty input schema, so there are no parameter semantics for the description to clarify. The baseline of 4 for zero-parameter tools applies 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 clearly states a specific action and resource: '列出当前用户名下的产品' (list the current user's products). It also specifies the output scope — all statuses and all links — which distinguishes it from sibling tools like list_products or search_products.

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 '【何时用】' section gives concrete use cases: getting a productId before modifying a product's links/profile, or taking inventory of published items. It provides clear context for when to use the tool, though it does not explicitly say when not to use it or name 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?

注解已声明 readOnlyHint、openWorldHint、idempotentHint，描述在此基础上补充了“需要登录”这一认证前提，并说明返回内容包含私有链接和 persona，这些是对注解之外有意义的行为披露。没有与注解矛盾之处。

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?

该工具无参数，注解已覆盖只读、幂等、非破坏性等安全属性，描述则补充了认证要求和返回数据的详细范围，并给出了与 get_creator 的对比。在无输出 schema 的情况下，描述列出的字段类别足以让 agent 理解调用结果。

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 为空，描述不需要解释参数。描述通过列出返回资料的字段类别，补充了输入 schema 无法提供的语义信息，符合 0 参数场景的基线水平。

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?

描述以具体动词“返回”明确说明该工具的功能是获取当前用户的完整资料，并列出昵称、简介、介绍、所在地、链接和 persona 等具体内容。它明确区分了与 get_creator 的差异（get_creator 仅公开视角），使 agent 能清楚识别此工具用途。

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

描述明确给出使用场景：在帮助用户填写资料到其他平台、检查联系方式、修改链接之前，先读取此工具的数据。还明确指出当需要公开视角时应选用 get_creator，提供了替代工具的选择依据。

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 a non-obvious side effect not fully captured by annotations: '读任务会幂等补齐周期任务的期次，故不是纯只读' — reading tasks idempotently fills recurring task periods, so this is not purely read-only. It also states the tool will not read or mark arrangements, and explains pagination and limits. This aligns with readOnlyHint=false and idempotentHint=true, adding meaningful detail beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every clause earns its place: purpose, pagination behavior, side effects, exclusions, and next-step routing. It is front-loaded with the core purpose, and the spatial separation of concerns makes the complexity navigable without 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?

Despite having no output schema, the description covers the key return behaviors: goal list limits and totals, nextOffset pagination, task reachingLimit and follow-up via list_collaboration_tasks, invite caps, side effects, and exclusions. It also notes login requirements. This is enough for an agent to select and invoke the tool correctly; the only minor gap is the undocumented includeArchived parameter.

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 does explain limit and goalOffset meaningfully: the goal list returns at most limit entries with a total, and goalOffset uses nextOffset for pagination and only affects the goal list. However, includeArchived is not mentioned at all, leaving one of the three parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('查看') and clear resources: collaboration goals, tasks pending on me or dispatched by me, and invites awaiting response. It also distinguishes itself from siblings by explicitly saying arrangements should use get_my_dispatch and goal details should use get_collaboration_goal, which prevents confusion with the many sibling get_* tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit routing guidance: when tasks have reachingLimit=true, call list_collaboration_tasks by goalId; for goal details use get_collaboration_goal; for progress reporting use set_collaboration_task_status; for invites use respond_collaboration_invite; for arrangements use get_my_dispatch. This directly tells the agent when to use this tool versus 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?

Beyond the readOnlyHint/idempotentHint annotations, the description discloses auth-dependent fields (isMine, displaying), not-found behavior (found=false), the semantics of displaying=false (manual delist, status stays OPEN), and the no-quota/no-reward business rule.

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 main purpose is front-loaded, and the additional domain rules, resource link, and follow-up route are separated into labeled sections. Every sentence adds operational value; there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of explaining return content, conditional fields, missing-record behavior, and critical display/status semantics. It also tells the agent what to do next, making it complete for a single getter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the only parameter id is already described as '需求 id（cuid）'. The description references '按 id' and the resource link but adds no substantive parameter details beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first line states a specific verb and resource: '按 id 查单条需求的完整卡片' and enumerates the returned fields. It clearly distinguishes this single-id detail getter from list/search/recommendation siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear context: use for a single need card by id, and explains not to recommend needs with displaying=false. It also routes to contact_need for taking the need, but does not explicitly contrast with sibling query tools like search_needs or list_needs_feed.

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

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

Annotations already signal readOnly/idempotent/non-destructive, and the description adds meaningful behavioral context: login requirement, authorization boundary with error name (not_your_need), soft downweighting of seen needs, and the scoring/weighting mechanism. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well structured with clear sections (【需要登录】【组合链】【越权】), front-loads the core purpose, and every sentence conveys distinct, useful information without 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?

Despite no output schema, the description names the returned fields and explains the authorization, pagination, and follow-up actions. For a read-only recommendation tool, this provides all essential context an agent needs to select and invoke 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 description coverage is 100% and already documents needId, seen, limit, and cursor with their intended usage. The description reinforces cursor and seen behavior but does not add material meaning beyond what the schema provides, 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 the action: fetch personalized recommendations for one of the user's own published needs. It specifies the matching logic, result fields (matchScore / matchReason / authorNeeds), and scope ('自己发布的', '别人的会被拒'), which distinguishes it from general feeds and search tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly frames when to use it ('发完需求主动出击的工具，不用干等撮合推送'), restricts it to one's own needs, and gives the follow-up chain: contact_need or start_conversation. It also explains pagination behavior with nextCursor and seen, leaving little ambiguity about how to invoke and continue using the 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?

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds value beyond that by requiring login and by enumerating the exact returned notification categories (follows, dms, activities, drops, matches, nudge), giving the agent a concrete picture of the response contents.

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, front-loaded with the login requirement and the core purpose. Each parenthetical explanation earns its place by clarifying a switch name without unnecessary 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 simple parameterless getter, the description is nearly complete: it identifies the resource, auth context, and all six returned fields. It does not specify the value format (e.g., booleans) or unauthenticated error behavior, but those are minor gaps given the low complexity and strong annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

This tool has zero parameters and the schema coverage is 100%, so there are no parameter semantics for the description to clarify. The baseline for a parameterless tool is 4, and the description appropriately focuses on the returned switches instead.

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 '返回当前用户的通知开关' (returns the current user's notification switches) and then enumerates each switch with a plain-language gloss. The read verb and specific resource clearly distinguish it from the sibling setter set_notification_prefs.

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 states the login requirement and scopes the tool to the current user's notification switches, giving clear context for when to call it. It does not explicitly name alternatives or exclusion cases, such as using get_my_preferences for broader preference retrieval, so it stops short of full routing 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds valuable behavioral context beyond this: login requirement, the prefill field's origin and meaning, the warning that prefill only reduces typing and never reduces confirmation requirements, and that prefill is null by default. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is organized into clear sections and front-loads the core purpose. It is somewhat long, and the prefill warning is repeated in two places, but the extra length is mostly justified because of the subtle and important prefill behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description fully compensates by enumerating the return fields and their exact semantics. It also covers login requirements, prefill behavior, and the downstream workflow, so an agent has everything needed to invoke and interpret this 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, so there are no parameter semantics to document. The baseline for 0-param tools is 4, and the description correctly avoids inventing parameter-related content.

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 specific verb '返回' with a clear resource ('当前用户的入驻引导状态') and enumerates every returned field. It also differentiates itself from siblings by positioning itself as the first step in the onboarding workflow, with complete_onboarding as the final step.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use this tool: when helping users '完成入驻 / 看还差哪步', read this first. It even provides the ordered sequence of sibling tools to call based on gaps. However, it does not explicitly state when not to use it or name 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?

Beyond the annotations (readOnlyHint=true, idempotentHint=true, etc.), the description discloses login requirement, the behavior of still returning results after an event is delisted/cancelled, and explicitly states the response contains no registrant data and no learnedPageKeys. These edge-case behaviors are not inferable from the schema or annotation, adding significant value.

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 organized into clearly labeled sections 【需要登录】【何时用】【组合链】【口径/坑】, front-loading the login requirement and usage context. Every sentence provides actionable information for the agent, with no filler or redundant restatement of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description enumerates the return content (event current values, formSchema, external form address, category, contact QR code, myAccess with possible values), exclusions (no registrant data, no learnedPageKeys), and the read-after-delisting edge case. This is sufficient for an agent to correctly call the tool and interpret its response for a single-parameter read operation.

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 schema already describes activityRef as '活动 slug 或活动 id'. The description's pitfall ① repeats this exact information, adding no new semantic detail about the parameter. The baseline of 3 is appropriate because the schema carries the full burden of parameter 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 states a specific verb (读/reads the complete configuration), names the resource (活动本体现值 + 报名配置 + myAccess permission), and distinguishes itself from siblings by excluding registrant data and learnedPageKeys. The combination chain explicitly routes to update_organizer_signup_config, update_activity, and list_signup_submissions, making differentiation 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?

It tells exactly when to use the tool: as the first step of read-edit-write before configuration changes, or when the user asks about their own activity configuration and registration form content. It also names the alternatives: update_organizer_signup_config for registration config, update_activity for event body changes, and list_signup_submissions for seeing registrants, so the agent knows which tool to select.

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

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

Annotations already declare readOnlyHint/idempotentHint, but the description adds meaningful behavioral context beyond them: 'found=false' when not found, and the crucial data-caliber warning that UGC check-ins/reviews are offline and must not be invented. This directly helps the agent avoid hallucinated content, which is a strong 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 well-structured: a front-loaded purpose sentence with a compact field list, followed by a clearly labeled '口径' section and a '相关' section. Every sentence earns its place, and the anti-hallucination caveat is placed where it will be noticed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema present, the description carries the burden of explaining return values, and it does: it lists the substantive content areas and the failure behavior ('查不到 found=false'). For a simple get-by-id tool with a single required parameter, this is complete enough for an agent to invoke 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 100%: the single parameter 'id' is already documented as '园区 id（cuid）'. The description only restates that the lookup is by id and adds no new format, constraints, or semantics beyond what the schema provides. This matches the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: '按 id 查园区完整详情', then enumerates the exact fields returned (subsidies, operator, address/coordinates, creators, channels, sources, news). This clearly distinguishes it from nearby list-style siblings like list_parks, and '查不到 found=false' further pins down its behavior.

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 makes the usage context clear: use with an id to fetch complete park details. It also names 'list_city_policies 查所在城市政策红利' as an alternative for city-level policy needs. It does not explicitly list exclusions for all sibling tools (e.g., list_parks or list_park_news), so it falls just short of a 5.

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

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

Annotations already mark the tool read-only, idempotent, and non-destructive. The description adds meaningful behavior beyond those: results include viewerHasLiked/isMine only when authenticated, and the content is predominantly official-generated with zero site-wide comments, which prevents the agent from suggesting a comment section that doesn't exist. This is valuable context the annotations do not convey.

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 paragraphs: the first states the operation and returned components; the second contains a single critical data caveat. Each sentence provides distinct information, front-loaded, and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, read-only, idempotent lookup, the description covers the return scope (body/media/attach/author), auth-dependent fields, the official-content origin, and the empty-comment warning. With no output schema present, the description sufficiently explains what to expect, and nothing essential is missing 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 already fully documents the single id parameter (type, required, description '内容 id（cuid）') with 100% coverage. The description only repeats '按 id' and adds no format, semantics, or edge-case information beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the exact operation (query by id), the resource (a single item in the content feed), and enumerates its components (body, media, attached card, author). This clearly differentiates it from sibling getters like get_activity, get_product, and get_creator, and from list_posts, which lists rather than fetches a single post.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the usage context: fetching a single content item by id, with login-dependent fields. It also provides situational guidance via the caveat about official content and empty comments. However, it doesn't explicitly name alternatives or exclusion criteria, such as pointing to list_posts for browsing the feed, so it lacks the explicit routing found in a 5.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond that: the two parameters are mutually exclusive, slug takes priority, and the returned detail fields are listed. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured with three labeled sections: action, when-to-use, and related resource. Every sentence earns its place, and the main behavior 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 read-only getter with no output schema, the description covers input selection, parameter precedence, usage scenarios, and the content of the returned detail. An agent has everything needed to 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 description coverage is 100%, so the baseline is 3. The description adds the important rule '两个参数二选一，slug 优先', which the schema does not encode (both are optional). This meaningfully improves invocation correctness.

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?

Description clearly states '按 id 或 slug 获取产品完整详情' and enumerates the fields returned (owner, description, links, media, categories, tags, publish time). It is unmistakably a single-product detail fetcher, distinct from list/search/rating siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The '【何时用】' section explicitly tells an agent when to invoke: when a user clicks a product or wants to expand a search/list result. It does not explicitly name alternative tools or exclusions, so it falls just short of a 5.

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

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

注解已经声明 readOnlyHint=true、idempotentHint=true、destructiveHint=false，因此安全画像由注解承担；描述额外补充了登录时附带 myRating、站内口碑刚起步导致多数产品为空返回等注解未覆盖的行为特质。这些信息有助于代理正确解释返回结果，但未涉及分页/游标行为，不过 schema 已覆盖。

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

描述用三段式组织：核心功能 → 口径/空结果提醒 → 写评价入口，核心信息置于开头，每条都有实际价值。没有冗余从句或重复 schema 内容，长度紧凑，可读性强。

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

虽然没有输出 schema，但描述明确说明了返回结构（星级汇总 + 评价列表）以及登录后额外附带 myRating，足够代理理解结果。空返回的常态性提示也很关键。唯一欠缺的是未提及同族工具 get_product_rating_summary 可用于仅获取汇总的场景，但对完成本工具的调用目标而言已足够完整。

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%，productId、sort、limit、cursor 都已有明确描述，因此描述无需重复参数含义。描述中“登录时附带 myRating”属于输出行为而非参数语义，没有为参数增加额外解释，按基线评 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?

描述以明确动词“返回”+ 资源“某产品的口碑”开头，并具体列出返回内容（星级汇总 + 评价列表），让代理立刻知道工具做什么。它还通过与 get_product（不含评价）和 rate_product（写评价）的对比，进一步界定了自己的定位，虽然未显式提及 get_product_rating_summary，但“汇总 + 列表”的组合已经足够清晰。

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

明确说明使用场景：“get_product 详情不含评价，要口碑必须调本工具”，并给出写操作的替代工具 rate_product。还专门提示“绝大多数产品是 0 条评价——空返回是常态，不是查询失败”，防止代理误判空结果并反复重试或去站外找数据，这是非常实用的使用边界。

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

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

Annotations already declare the operation read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond that: it returns only aggregate rating data, not the review list, and frames itself as a token-saving summary call. It does not specify the exact distribution shape or edge cases like zero ratings, but the added context is meaningful.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the core purpose and contents, followed by an explicit sibling alternative. Every word earns its place; no filler or repetition of schema/annotation data.

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 read-only tool with no output schema, the description is complete: it names the input, specifies what the output contains, and points to the alternative for detailed reviews. Nothing essential is missing 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?

Schema description coverage is 100%, and the single parameter productId is already documented as '产品 id（cuid）'. The description adds no new parameter-level detail, so the baseline of 3 is appropriate because the schema carries the burden.

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-resource pair ('取某产品的星级汇总') and spells out the exact contents: average, distribution, and total. It also explicitly distinguishes itself from get_product_ratings by stating that it does not pull the review list, so an agent can tell them apart immediately.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states when to use this tool ('省 token 的「评分多少」快查') and gives a direct alternative: '要看评价文字用 get_product_ratings.' This is explicit routing guidance with no ambiguity.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds the login requirement, which is not present in the annotations, and clarifies the exact meaning of each returned relationship state. No contradiction with annotations exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense sentence that front-loads the login requirement, states the return object, defines each field, and gives practical decision guidance. Every element earns its place with no redundant 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 simple read-only tool with one parameter and no output schema, the description is complete: it covers authentication, return value semantics, and the decision context. There are no critical gaps that would prevent an agent from calling this 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 input schema already documents userId as '目标用户 id' with 100% coverage, so the description doesn't need to add much. The description adds context about the target user's role in the relationship, but it doesn't provide additional parameter-level detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it returns the relationship between the current user and a target user. It explicitly enumerates the four relationship states (following, followedBy, isFriend, isSelf), making the tool's purpose unmistakable and distinct from siblings like follow_creator or unfollow_creator.

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 for when to use this tool: to decide whether to follow the target user or determine they are already a friend. It doesn't explicitly name alternative tools or state when not to use it, but the practical decision context is clear enough to guide tool selection.

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?

Goes well beyond the readOnly/idempotent annotations by disclosing the login requirement, the absence of public image URLs, the private rendering API for card images, the instruction to share only shareText+link, and exact failure semantics (found=false and 403 cases). This is thorough 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?

Well-structured and front-loaded: it starts with the auth requirement, then the return value and use case, and uses labeled sections for kind values, image caveats, and failure semantics. Every section contributes operational value with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given there is no output schema, the description covers return contents, auth, kind/id combinations, an important image-sharing caveat, and failure behavior. The only notable gap is that the 'activity' enum value is not explained, so one valid invocation path remains partially unspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Adds substantial meaning beyond the schema, such as owner being usable for self or others, card/position/onboarding requiring id='me', and position being the only share outlet for the positioning bar. However, the enum includes 'activity' but the description does not explain it, leaving one valid kind semantically undocumented.

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 operation: return a share-card manifest containing shareText and a link, plus card metadata. It also ties the tool to a clear user scenario—helping an agent share a profile or need—making it easy to distinguish from generic getters and from send_share_card.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when to use the tool: when the agent helps the user share their home page or need by fetching ready-made copy and a link for forwarding. It does not explicitly name alternatives or state when not to use it, so it falls just short of the highest bar.

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

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

Annotations already mark the tool readOnly, idempotent, and non-destructive, and the description adds substantial behavioral context beyond them: it does not return autofillScript, valuePreview values are masked, externalIsCanonical changes the meaning of submission, requiresPhoneVerification does not apply to the authenticated agent, and canOneClick=false without externalUrl means submit_signup will reject. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but organized into three labeled sections—when to use, combination chain, and pitfalls—with numbered items. Every sentence carries operational value, from '绝不许瞎编' to '别拿这个字段去劝退用户', and the load-bearing info 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?

Despite no output schema, the description tells the agent what the call returns (public details plus my status, current answers, missing required fields), how to chain follow-up tools, and six edge cases that affect downstream behavior. This is complete for safe and 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 covers the only parameter fully (slug minLength 1, described as '活动 slug（取自 list_signup_feed 的 items[].slug）'), so the baseline is 3. The description also references slug in the submit chain, but it adds no new semantic details 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 an explicit trigger ('用户对某一场感兴趣、或准备报名之前调它') and a precise verb+resource: one call returns both public signup details and the caller's signup status. It also differentiates itself by naming related tools in the combination chain, so an agent can separate it from get_signup_gaps, submit_signup, and list_my_signups.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states exactly when to call and gives a workflow: if viewer.missingRequired is non-empty, ask the user and call submit_signup; if gaps span other sessions, use get_signup_gaps; if already submitted, use list_my_signups. This is explicit when-to-use/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?

Beyond the annotations (readOnlyHint, idempotentHint), the description discloses login requirements, cross-activity deduplication behavior, fillable=false attachment semantics, exclusion of submitted activities, the 10-activity limit, server-side batching, and explicitly warns the agent not to perform set operations manually. This is rich, non-obvious behavioral 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 dense but well-structured with clear headers (需要登录/何时用, 组合链, 口径/坑) and front-loaded use cases. Every sentence carries actionable information; the length is justified by the tool's complexity and the need to prevent common agent mistakes.

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 and absence of an output schema, the description adequately covers return semantics (missingCombined with activities), edge cases (fillable=false, submitted=true), scope limits, and the downstream workflow. An agent has enough context to invoke the tool correctly and interpret its results.

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 already 100%, so the parameters are documented. The description adds important semantics beyond the schema: omitting slugs auto-selects unsubmitted activities from list_signup_feed, limit defaults to 5, and the 10-activity cap is tied to server-side batching. This meaningfully enriches 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 clearly states the tool computes gaps across multiple signup activities at once and deduplicates common questions, which goes well beyond the name. It also explicitly contrasts with get_signup_activity for viewing a single activity's full question set, making the tool's purpose and boundaries 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 何时用 section gives explicit trigger conditions: the user wants to batch-sign-up or asks what is missing across all signable activities. The 组合链 section specifies the exact workflow with list_signup_feed, update_my_signup_profile, and submit_signup, and names get_signup_activity as the alternative when a single activity's full form is needed.

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

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

Annotations already mark it read-only/idempotent, and the description adds meaningful behavior: login required, ID numbers never decrypted, registered-account phone masked to last 4 while form-entered phone is returned, and not to recite the full contact string in conversation unless requested. It also discloses the 404 for a submissionId outside the activity. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Though long, the description is organized into clearly labeled sections (when, chain, caveats) and every sentence carries operational value. The key scoping fact—contact info is only decrypted here—is front-loaded. For a privacy-sensitive tool, this density is appropriate, not bloated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With only two simple parameters and no output schema, the description covers all an agent needs to invoke and use it correctly: exact triggers, chain inputs, masking rules, privacy behavior, error condition, and the returned user.id condition for the conversation sibling. Nothing material 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 descriptions already cover both parameters (slug and submissionId, with source via list items). The description adds the validation constraint that submissionId must belong to the given activity or return 404, and reinforces the chain relationship to list_signup_submissions. This modest addition above the 100% schema coverage merits a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description states the tool fetches one signup submission's full answers and decrypted contact info (WeChat/email/phone), which matches name and title. It explicitly differentiates from list_signup_submissions by saying that list excludes contact details by default. The purpose is unmistakable.

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 '何时用' section gives precise trigger conditions: user explicitly asks to contact the person, get WeChat, or see what they submitted. It also provides a full chain listing list_signup_submissions for locating the row, review_signup_submission for disposition, and start_conversation with a condition (only if registered user via returned user.id). This clearly tells the agent when to use it and when to use 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?

Beyond the annotations (readOnlyHint=false, idempotentHint=false), the description discloses multiple important behaviors: the invitee is notified, valid pending invitations to the same person are reused, there is no persistent or concurrent deduplication guarantee, and no persistent request dedup key exists. This materially affects how an agent should invoke and verify the call. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and information-dense: each sentence adds a distinct constraint or caveat, and the core action plus login requirement is front-loaded. It is structured and free of filler, though the density makes it slightly harder to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutating tool with no output schema and no parameter descriptions in the schema, the description covers the main operational risks: authorization, notification side effects, scope limitation, non-idempotency, dedup limits, and timeout handling. It even gives partial return information by stating what the response excludes. It does not describe the success response shape or the exact meaning of message/contribution, so minor gaps remain.

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 for the four parameters, but it only refers to them indirectly via phrases like '指定站内用户' and '目标发起人'. goalId and inviteeId can be inferred, but message and contribution are never explicitly explained, and the required parameters are not called out in the description. The global context helps, but per-parameter meaning is largely left to inference.

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 concrete action: the target initiator sends a collaboration invitation to a specified in-site user and the user is notified. It also narrows scope with '仅支持站内定向邀请' (only targeted in-site invitations), which distinguishes this from external or bulk invitation flows. This is far more specific than the tool title alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit prerequisites and boundaries: login is required, prior authorization of the invitee and content is needed, only on-site targeted invitations are supported, and the response will not contain phone numbers or forwardable tokens. It also tells the agent what to do on ambiguous results or timeout: query current state first and do not auto-resend. This is strong operational guidance.

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