独行录 / 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?

在注解已声明写操作、开放世界、非幂等且非破坏性的基础上，额外披露了需要登录且为主办方、缺省 confirmed=false 不上公开页、仅在对方明确同意并同意展示时才传 true、每场最多 30 位、本工具不通知任何人、头像由嘉宾自助上传等关键行为。这些信息远超注解覆盖，且与注解无冲突。

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，描述完整覆盖调用前提（登录/主办方）、在业务链中的位置、参数默认值与限制、容量上限（30 位）、通知行为及头像处理方式。对于一个无输出 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%，各参数含义已由 schema 提供。描述额外补充了‘每场最多 30 位’等约束，但对具体参数的语义说明基本重复 schema（如 confirmed 缺省值、userId 用途），未在参数层面提供实质性增量信息，符合 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?

明确说明具体动作：将某人录入活动嘉宾阵容，站内用户挂 userId，并指出这是邀请嘉宾的第一步。通过组合链和‘本工具不通知任何人’与 create_guest_invite_link、send_guest_invite_now 等兄弟工具区分开。

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?

给出完整的工具编排链：search_people 核对身份 → 本工具 → create_guest_invite_link → start_conversation/send_message 发送并确认。同时说明 confirmed 参数的使用条件，明确何时传 true。虽然未列出‘何时不用’，但链式上下文和替代步骤已经足够明确。

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 cover the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false). The description adds substantial behavioral context beyond them: login/organizer requirement, server-side fetch into private storage, image moderation, broadcast of 'material online' to registrants for SLIDES/FILE, visibility defaults, 30MB size cap, direct-link requirement, and a pre-call confirmation step. This is rich 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 with bracketed sections and the login/organizer requirement front-loaded. It is dense but each section (purpose, chain, pitfalls) earns its place. Slightly long, but the length is justified by the number of important constraints it must convey.

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?

Complete for a mutation tool with no output schema. It covers authentication requirements, server-side behavior, workflow ordering, visibility defaults, size limits, link requirements, and a pre-call confirmation instruction. Nothing critical 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 description coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: default visibility logic (PHOTO defaults to PUBLIC, other kinds to REGISTERED), kind-specific broadcast behavior, the 30MB per-file limit, and the direct-download-link constraint. It does not add much for activityRef, but overall it exceeds the schema baseline.

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

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

States a specific verb and resource: registering a public web file link as an activity material. It names supported material types (handout PDF/PPT, document, photo) and explicitly differentiates from siblings through the chain pointing to list_activity_materials and update_activity_material. An agent can identify what this tool does without inspecting the schema.

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

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

Explicitly gives the workflow chain (this tool → list_activity_materials to verify → update_activity_material for renaming/visibility) and a concrete alternative for oversized files (>30MB use web /pro direct upload). These are named alternatives with the conditions that select them, 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 only indicate readOnlyHint=false, but the description adds significant behavioral context: it runs vector recall + model judgment, takes tens of seconds, costs money, sets the plan to a 'pending review' pause state, and returns 'exits' when no new person is found. This goes well beyond the annotations and discloses side effects and performance characteristics without contradiction.

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 with clear sections (when to use, combination chain, scope) and front-loaded with the primary usage condition. It is dense but each part is informative and necessary given the tool's complexity. Slightly lengthy but not wasteful, earning a 4.

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 and organizer requirement, when to use, side effects (cost, time, plan state change), and an edge case (exits on no results). No output schema exists, but the description provides sufficient operational detail for an agent to decide and call it correctly. Minor gaps like full return structure do not impede usage.

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 both parameters are fully described (role enum with default and restriction, activityRef with source). The description reiterates the role constraint but adds no new parameter meaning beyond the schema. A baseline of 3 is appropriate since the schema carries the semantic weight.

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 it appends a batch of guest candidates for SPEAKER without reordering existing ones. It distinguishes from update_guest_candidates by specifying it only adds, and from set_guest_invite_plan by placing it in a workflow chain. The verb+resource is specific and unambiguous.

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

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

Explicitly states when to use ('when existing candidates are insufficient or mismatched'), restricts to SPEAKER only, and provides a combination chain with set_guest_invite_plan and get_activity_invites. It also warns against calling twice consecutively due to cost, giving clear 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?

Annotations only provide low-level hints (write, not idempotent, not destructive). The description goes well beyond them by disclosing the login requirement, type-dependent privacy defaults, and the important consequence that public links are visible to anyone via get_creator. It also requires explicit user confirmation before making contact info public, which is critical 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 compact and well-structured: login requirement and purpose first, privacy defaults second, and a concrete example third. Every sentence contributes to a decision the agent must make, and the most safety-critical instruction is bolded and 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 4-parameter mutation tool with no output schema, the description covers the login requirement, type domain, visibility defaults, privacy caveat, and a runnable example. It does not describe the return value or duplicate-type behavior, but neither is needed to select and invoke the tool correctly. The safety-relevant information is fully 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 baseline is 3. The description adds real value by explaining the default visibility mapping by type, the rule that public must be explicit, and the privacy exposure via get_creator. It also gives a concrete example for type, url, and visibility that goes beyond the raw schema text.

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: adding a link to the current user's profile. The qualifier '不动其它字段' clarifies this is additive rather than an update, and '当前用户' identifies whose profile is modified. This makes it easy to distinguish from 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?

Provides clear usage context: requires login, adds a link to the current user, and includes a concrete example mapping user intent to parameters. It does not explicitly name sibling alternatives like remove_profile_link or set_link_visibility, nor state when not to use this tool, so it misses the full 5-level 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, the description discloses meaningful privacy behavior: analysis will not inform the counterparty or modify the plan, and research never sends private plans or personal data to search. This adds security and side-effect context that the schema and annotations do not provide. It does not contradict readOnlyHint=false because it only claims no plan modification, not no side effects at all.

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 four short sentences, front-loaded with the most important constraint ('only current user-visible plans'), and every sentence adds meaningful privacy or authorization guidance. There is no filler, though the density of multiple constraints in one sentence slightly reduces skimmability.

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?

This is a complex 11-parameter tool with nested objects and no output schema. The description thoroughly covers privacy and research constraints but omits operational essentials: what the analysis should be based on, how message/selection/context interact, what output the agent should produce, and what expectedRevision/expectedDocumentHash protect against. The agent would need to infer too much.

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 needs to compensate. It does explain useMyProfile and research.industryTopic, but it leaves 9 other parameters (message, planId, context, history, selection, requestId, shareAccessId, expectedRevision, expectedDocumentHash) entirely to their names. Given the complexity of nested objects and versioning fields, this is insufficient.

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 establishes the tool as a private analysis advisor over cooperation plans, with phrases like '只用当前用户可见方案' and '分析不会告知对方或修改方案.' The core action 'analyze' is implied by the name/title and the repeated use of '分析,' and the resource is clear. However, it does not explicitly differentiate itself from siblings such as get_cooperation_analysis or get_cooperation_plan.

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 useful conditional rules: useMyProfile requires user authorization, and research must be explicitly requested with a de-identified public industry topic. It also limits the tool to plans visible to the current user. It lacks an explicit 'use X instead' comparison with sibling tools, but the preconditions and exclusions are clear enough for an agent to decide when this tool is appropriate.

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 critical behavioral traits: login is required, the submission is real and immediately visible to admins, the caller must obtain explicit user consent before invoking, and the idempotent short-circuit returns the existing record rather than new progress. It also explains that invitationToken grants pre-approval and instant membership. This is far beyond what readOnlyHint/destructiveHint/idempotentHint provide.

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 labeled sections (【需要登录】【组合链】【口径/坑】) and numbered pitfalls. Every sentence carries operational value, and the most critical item—user consent before calling—is front-loaded. No filler 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?

Although there is no output schema, the description covers the full workflow: how to retrieve terms and form fields, what response states mean (joined=true vs pendingReview=true), how to proceed next with submit_signup, and the idempotency caveat. It is complete enough for an agent 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?

Schema description coverage is only 20%, but the description compensates thoroughly: termsVersionId must equal currentTerms.id, acceptTerms must be true and should be omitted entirely when there are no terms, invitationToken is 43 characters and implies pre-approval, and answers keys must come from formFields[].key. This adds decisive meaning to otherwise undocumented parameters.

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

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

The description opens with a specific verb and resource: applying to join an organization on the user's behalf ('以用户本人名义申请加入'), and immediately clarifies that it is a real submission visible to admins. This distinguishes it from admin-side review tools like bulk_review_organization_applications.

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 an explicit combination chain (get_organization → this tool → submit_signup) and clear conditions for when to call it, including the prerequisite of reading terms and form fields. It also gives a when-not-to-treat-as-success case: if the user is already a member or has a PENDING application, the server short-circuits. It stops short of naming explicit sibling alternatives, so a 4 is appropriate.

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 what annotations convey, the description discloses a significant side effect: goal collaborators automatically become administrators of the attached activity. It also exposes the 409 failure case, login requirement, and the 'must be my activity' ownership constraint, giving the agent important 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 well-structured with clear sections: when to use, combo chain, and pitfalls. Every sentence adds actionable information, and the most important context (login, usage, side effects) is front-loaded 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 provides a verification workflow via get_collaboration_goal(include:["activities"]). It covers prerequisites, authorization, error behavior, and the side effect on administrators, making it sufficient for an agent to invoke correctly.

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

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

Schema coverage is only 50%, but the description compensates by clarifying activityRef as a slug or id obtainable from list_my_activities or get_collaboration_goal(include:["activities"]). It also clarifies the goalId context as a collaboration goal requiring collaborator permission, although goalId itself is not explicitly labeled in a dedicated parameter note.

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: attach an activity that "我举办的" to a collaboration goal, making it a module of that goal. It also distinguishes itself from the inverse sibling detach_activity_from_goal, so an agent can 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?

It explicitly marks when to use the tool with 【何时用】, provides a complete combo chain (list_my_activities → attach → get_collaboration_goal), and names detach_activity_from_goal as the inverse operation. It also documents required permissions and exclusion cases like org-owned activities failing against personal goals.

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?

Beyond the annotations (destructive=true, not read-only), the description discloses that results are pushed to applicants and cannot be undone, that preview is a dry-run, that execution is serial with partial success, and that already-resolved applications cannot be overturned. It also explains rate-limit behavior and the applicant-visible nature of the reason field. 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 dense but well-organized with clear sections for login/limits, the critical preview safety warning, the combination chain, and pitfalls. Every sentence carries operational importance, and the most critical safety constraint (preview true/false) is highlighted. 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 destructive batch mutation tool with no output schema, the description covers auth, batch limits, preview workflow, serial execution, partial success reporting, failure reasons, and retry semantics. An agent can call this tool correctly and handle expected edge cases without additional information.

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 covers 100% of parameters, providing a 3 baseline. The description adds meaningful context beyond the schema: preview must be explicitly false to execute, reason is shown verbatim to applicants, and failure codes such as organization_application_resolved and organization_rate_limited are explained. This elevates it above baseline.

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

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

The description states a specific verb and resource: '一次处置最多 100 条入会申请' (process up to 100 join applications at once). It is clearly distinguished from siblings by naming the companion tool 'list_organization_applications(pendingOnly=true)' and by scoping to organization applications, which separates it from bulk_review_signup_submissions.

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 an explicit combination chain: list → preview=true → user confirmation → preview=false → report succeeded/failed. It also gives prerequisites (login, OWNER/ADMIN) and retry guidance for rate limits. It does not explicitly name sibling alternatives or exclusions, but the workflow is concrete enough to guide an agent.

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?

Annotations declare destructiveHint=true and the description confirms this with the explicit **不可逆** (irreversible) warning and the concrete consequence: the invite vanishes from the other party's pending list. It also discloses the auth requirement (only the goal initiator can withdraw), the error condition (not in pending state), and advises against futile retries — substantial behavioral context well beyond what the annotations alone provide.

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 labeled sections (login, when-to-use, combination chain, pitfalls) and front-loads the most critical facts. Every sentence earns its place — the chain, the auth restriction, the irreversibility warning with user-confirmation instruction, and the no-retry error guidance are all essential and none are redundant.

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 tool with no output schema, the description covers everything needed to call it correctly: prerequisite (login + being initiator), parameter acquisition via the chained tool, irreversibility, error conditions, and the correct recovery action. Nothing an agent needs in order to execute or safely reason about this mutation 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 0%, so the description must compensate for the single undocumented parameter. The combination chain explains exactly how to obtain inviteId — get_collaboration_goal(goalId, include:["invites"]) — and discloses that it is only visible to the goal initiator. This adds real meaning beyond the schema's bare maxLength/minLength constraints, though it stops short of describing the ID's format.

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 (撤回/withdraw) + resource (collaboration invite) with a precise scope: only invites this goal sent out that haven't been responded to yet. This clearly distinguishes it from siblings like respond_collaboration_invite (responding to an invite received) and invite_collaboration_member (creating an invite), so an agent can select it correctly without opening any schema.

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

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

An explicit 【何时用】(when to use) section sets the trigger condition and even notes the App lacks this entry point, which justifies the tool's existence. Pitfall ③ adds a when-NOT-to-use rule (already accepted/declined/expired) plus the corrective action (check if they've joined). It doesn't name a specific sibling to prefer instead, but the boundary is clear enough that an explicit alternative isn't necessary.

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 significantly extends beyond annotations: it discloses the login/organizer requirement, batch limit, per-item independent execution with partial failure, idempotency details, side effects on published groups, exemption from the sign-in time window, and specific error codes. This is far richer than the readOnly/destructive/idempotent hints provided.

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 with labeled sections (前提, 何时用, 组合链, 口径) and a numbered list of constraints. Every sentence carries operational value, and the key trigger and limitations are front-loaded. The length is justified by the batch-check-in complexity.

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 no output schema, the description covers all critical invocation context: authorization, input provenance, batch maximum, idempotency, side effects, error semantics, and a verification step via get_activity_attendance. The only minor omission is an explicit response shape, but the suggested follow-up workflow compensates for 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 100% and parameter descriptions already point to source endpoints. The prose adds meaningful semantics by explicitly rejecting phone numbers/nicknames in favor of internal userIds, explaining the rationale, and clarifying activityRef as slug or id from specific list endpoints. This goes beyond the generic 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 action ('批量核销' / batch check-in) on a specific resource (attendees of an activity), with a clear user-trigger scenario. It also clarifies the batch limit and contrasts it with the manual web interaction, making it distinguishable from sibling tools like bulk_review_signup_submissions.

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

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

The description gives an explicit trigger ('用户报「这几位都到了，补一下」时') and a combination chain with specific sibling tools for obtaining userIds and verifying results. However, it does not explicitly name alternative tools it should be used instead of, so the vs-alternatives guidance is not fully complete.

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?

The description goes well beyond the annotations by disclosing critical behaviors: '认领不可撤销' (irreversible), '只插不覆盖' (only insert, never overwrite), 'accept 必须显式传 true', and the state change to '已认领' for the organization. It also explains the canFill=false condition and filledCount behavior, providing detailed insight into side effects and idempotency nuances.

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 with clear sections (【需要登录】【组合链】【口径/坑】) and every sentence adds value—login requirement, confirmation necessity, purpose, chain, and pitfalls. It is longer than a simple one-liner, but the density is justified by the complexity of the operation. Minor redundancy: the title and opening sentence both express the core action.

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

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

The description covers prerequisites (login, user confirmation), the work flow, edge cases (canFill=false, filledCount < fieldKeys length), and state changes. It omits explicit error handling or empty array behavior, but given the openWorldHint and schema constraints, an agent can reasonably infer these. The output is not described, but since no output schema exists, the mention of filledCount provides a partial hint.

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 only 33% schema coverage, the description partially compensates: it explains 'accept' must be explicitly true, and 'fieldKeys' should be passed all at once. It also references canFill=false which relates to field-level constraints. However, it doesn't elaborate on the individual enum values or the exact structure of fieldKeys, though those are self-explanatory in 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+resource: '把一条待认领资料里选中的字段一次性回填进我的报名资料层' (claim and backfill selected fields into my signup profile). It clearly differentiates from siblings like list_my_organization_claims and dismiss_organization_claim by naming the action and its role 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?

The description provides a clear combination chain (list_my_organization_claims → this tool → get_signup_gaps → submit_signup) indicating when to use it. It also contrasts with the App's manual step-by-step confirmation, framing this tool as the batch alternative. It doesn't explicitly exclude other update tools, but the context and chain make the usage situation 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 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?

The description adds substantial behavioral context beyond annotations: requires login, actually invokes an LLM (costs money), one call per item, serviceDomain=null is normal (not a failure), and category falls back to OTHER. These are critical for proper usage and are not derivable from the annotations (readOnlyHint false, idempotentHint true, destructiveHint false). No contradiction.

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 (需要登录, 组合链, 口径) and front-loads the core purpose and the key 'does not persist' point. Every sentence contributes meaningful guidance; there is no fluff 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?

The tool has no output schema, but the description explains the return fields (category, tags, serviceDomain) and clarifies the meaning of serviceDomain=null and the OTHER fallback. It also covers cost, usage pattern, and the relationship to the write path. This is comprehensive for a non-persisting helper 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 already covers all parameters with descriptions (100% coverage). The description adds value by advising that the description parameter should be written as specifically as possible for better accuracy ('写得越具体判得越准'), and reiterates that tagline may be empty. This goes slightly beyond the schema, justifying 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?

The description clearly states the tool's function: send product copy to machine judgment and receive category + tags + serviceDomain. It distinguishes itself from siblings by explicitly noting it does not persist or touch existing products, and references create_product/update_my_product as the real submission path. The verb and resource are specific.

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 explicit usage guidance: use for trial before publishing or for diagnosing against existing published products. It names the alternative tools (create_product/update_my_product) and describes the composition chain, including that there is no separate write endpoint. The '口径' section further clarifies expected behavior and pitfalls.

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 flag destructiveHint=true and idempotentHint=false, and the description goes beyond them: it discloses irreversibility, no rollback for already-completed sub-steps, partial failures, and two permission boundaries (only poster can unpublish, only initiator can change status). This is exactly the behavioral context an agent needs before calling a destructive cascade.

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 organized: when-to-use, what the tool does, the preview chain, then caveats. Every sentence carries operational value and the content is front-loaded; no filler or repeated schema text.

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

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

For a destructive multi-step mutation with no output schema, the description covers trigger, actions, preview flow, failure semantics, permission restrictions, and even the shape of an important response field (skipped=not_your_need). 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 already documents status enum values and preview semantics; the description adds little about goalId, which is undocumented but simple. It does map user intent ('做完了/不做了') to status choices and explains the preview-then-execute chain, but that is more usage behavior than parameter detail, so a moderate score 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?

Description names a specific verb+resource (closing a collaboration goal) and precisely enumerates three cascading effects: status change, unpublishing recruitment needs from the public feed, and stopping period-generating rules. It explicitly distinguishes itself from update_collaboration_goal by stating that a plain status update does not cascade.

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 an exact trigger condition ('用户说这个目标做完了/不做了') and explicitly warns against using update_collaboration_goal alone. It also routes to unpublish_need for needs posted by other collaborators, so the agent knows when to delegate instead of invoking this tool.

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

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

Beyond annotations (idempotentHint=true, destructiveHint=false), the description reveals concrete behavior: already-collected leads are returned unchanged, archived leads are revived, self/unusable accounts are skipped without aborting the batch, and login is required. This is rich behavioral disclosure that materially affects how an agent should call and interpret the 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 but information-dense, organized into labeled blocks (login/basic behavior, combination chain, signup-chain warning, rejection semantics). Every line earns its place, and the core function is front-loaded before the workflow and 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?

For a mutating batch tool with no output schema, the description covers the essential operational facts: authentication, batch size, idempotence/revival, per-item failure behavior, anonymous-submission handling, and tag conventions. An agent has enough to select and invoke the tool correctly without additional context.

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

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

Although the schema already documents the three parameters, the description adds decision-relevant semantics: userIds are site-internal users, tags should carry only the activity identifier (example '0921活动'), and note must not contain raw signup answers. These constraints are not inferable from the schema alone.

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: '把一批站内用户一次收进线索池' (collect a batch of internal users into the lead pool), immediately clarifying this is a batch collect operation with a 20-user cap. The chain references to search/list tools vs scan_broker_matches help distinguish it from adjacent steps, and the batch framing separates it from single-create siblings like create_broker_lead.

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 explicit workflow chains: search_people/list_talent/list_broker_fresh_joiners → collect_broker_leads → scan_broker_matches, and a separate signup-submission chain that only an agent should run. It also states when not to proceed (anonymous submissions without userIds should be skipped and the skip count reported), which is clear when-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?

Annotations only declare it is a non-idempotent, non-destructive write. The description adds meaningful context beyond that: login required, notifications fired to the author (and the replied-to user), public visibility, and a confirmation-before-sending policy. This is exactly the extra behavioral context a mutation tool needs.

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?

Bracketed sections (login / chain / caveats) front-load the auth requirement and keep the operational routing tight. It is somewhat dense, but nearly every clause carries actionable information.

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

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

With no output schema, the description still covers auth, side effects (notifications), visibility policy, the ID-sourcing chain, and content constraints. An agent has everything needed 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 100%, so the baseline is 3. The description reinforces replyToCommentId's meaning and its notification consequence, but also introduces a character-limit conflict: it says 正文 1 到 500 字 while the schema's content maxLength is 1000, which could mislead on length boundaries.

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 (评论/comment) and resource (消息圈/moment), and explicitly covers both modes: a direct comment and a reply when replyToCommentId is passed. An agent can distinguish it from sibling tools like like_moment or publish_moment without opening the schema.

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

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

The 【组合链】 section gives explicit prerequisites and alternatives: fetch momentId/commentId via list_moments_feed or get_moment, and use list_moment_notices first when replying to interactions received. When-to-use and sibling routing are both spelled out.

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?

The annotations already declare readOnlyHint=false and idempotentHint=true, and the description goes beyond them by disclosing that the action only archives an account/name declaration, that identityVerified=false, and that this is not verified real-name or formal e-signing. It also clarifies that legalName must come from the user, not be guessed, which is important 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 three dense sentences with no filler. The most important condition (only after user confirmation) is front-loaded, followed by parameter guidance and legal caveats. Every sentence adds 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?

For a confirming/writing tool with no output schema, the description covers the trigger condition, required values, user constraint on legalName, and the legal non-status of the confirmation. It does not specify the response or failure behavior, but that is not essential for correct invocation 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?

Schema description coverage is 0%, so the description must compensate. It explains the meaning of revision/documentHash ('use server-side revision/documentHash') and the optional legalName plus its user-only constraint. requestId is not explained, but the acknowledged parameter is self-documenting via const:true in the schema, so the compensation is mostly adequate.

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 (确认/confirm), a specific resource (合作当前版本/cooperation current version), and the required precondition (user personally views and confirms). It clearly distinguishes this from related cooperation tools by emphasizing it is a confirmation of the current version, not a proposal, request, or negotiation.

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 when-to-use guidance: only after the user personally views and explicitly confirms. It also gives clear exclusions: do not auto-confirm and do not confirm on behalf of the other party. This is strong usage direction even without naming specific sibling 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?

Annotations already cover mutation/idempotency/open-world, but the description adds substantial behavior beyond them: login requirement, that the need is not taken down by contact, idempotent replay returning the existing conversation, and detailed failure semantics (400 own-need, 404, 409 closed with the displaying-boolean判据, 429 quota with no-retry guidance). This is rich, actionable disclosure; the only gap is no mention of return payload shape, though conversationId is named.

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 front-loaded and organized with bracketed section headers (需要登录, 组合链, 失败语义, 可选 message). Every block carries useful operational detail; density is justified for a multi-failure, chained tool, though it is heavier than strictly necessary.

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

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

No output schema exists and the description compensates by naming the return value (conversationId) and enumerating error codes with their meanings and retry guidance. For a tool with only 2 params and no annotations gaps, this is complete enough 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%, so both parameters are already documented. The description still adds value by clarifying message semantics (first message sent in your name, plain text ≤2000) and advising the greeting be bundled into this call to avoid double confirmation, which is guidance the schema's terse text does not convey.

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

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

States a specific verb+resource: '找他聊聊' – establishing a 1-1 conversation with a need's initiator and registering the contact. It immediately distinguishes itself from siblings by naming send_message, get_conversation_needs, and complete_need in the follow-up 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?

Explicitly prescribes the workflow: optionally call get_conversation_needs first for context, then send_message in the returned conversation, and complete_need after delivery. It also states eligibility ('anyone can contact, no cap') and idempotency, leaving nothing to inference.

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

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

The description adds substantial behavior beyond the annotations: login requirement, no deduplication at the service layer, phone number as the attribution anchor with claimedUserId as the success signal, and masked phone numbers in responses. None of this is visible in the annotations alone.

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

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

The description uses labeled sections and bullet points, front-loading the purpose and then adding workflow and caveats. Every sentence carries distinct, non-redundant information, making it dense yet easy to scan.

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

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

For a 10-parameter create tool with no output schema, the description covers auth requirements, field scope, workflow chain, attribution semantics, dedupe behavior, and response masking. It is complete enough for an agent to call the tool correctly without guessing.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain phone semantics in depth and mentions fields like wechat/position/city/tags that are unavailable in the App form, but leaves canOffer, note, and title to name inference. It partially compensates but not fully across all 10 parameters.

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

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

The description states a specific action and resource: '往池子里加一条站外线索' (add an off-site lead to the pool). It also distinguishes itself from import_broker_leads by explicitly noting the dedupe difference, making it clear this is for manual single-lead creation.

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 routes repeated imports to import_broker_leads ('重复导入请用 import_broker_leads（按手机号合并）') and provides the intended follow-up chain (create_broker_lead → scan_broker_matches → create_broker_match). It also explains why this tool is needed despite the App form's limitations.

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 annotations: idempotency (no mirror records on repeat calls), the side effect of marking both leads as worked=true (a billing/revenue field), and the partial-failure behavior (single failure doesn't abort the batch). It also notes the login requirement. These are exactly the kind of behavioral details an agent needs. The annotations (idempotentHint=true, readOnlyHint=false) are consistent with the description.

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

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

The description is dense but well-organized with clear sections (【需要登录】, 【组合链】, 【口径】). Every sentence carries operational weight. It's longer than average, but the complexity of the tool (batch, idempotency, side effects, field semantics) justifies the length. Slight deduction for the dense Chinese formatting that might be 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 batch mutation tool with no output schema, the description covers everything an agent needs: prerequisites (login), batch limits (20), idempotency, side effects, field semantics, error handling, and the surrounding workflow. The sibling list provides additional context for routing. 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?

Schema coverage is 100%, so the schema already documents all parameters. The description adds value by explaining the bUserId vs bLeadId choice ('对方只有站内用户 id、还没收进池的，直接传 bUserId，服务层会先收进池再配') and by clarifying the reason field's semantics ('别写分数'). It doesn't repeat schema details but adds operational meaning.

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

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

The description clearly states the tool's purpose: batch-create broker matches (up to 20 pairs) for pairs the user has approved. It specifies the resource (broker matches), the action (create), and the batch nature. It also distinguishes itself from related tools like introduce_broker_match and get_broker_intro_scripts by showing the workflow 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?

The description provides explicit usage context: it should be used after scan_broker_matches and before get_broker_intro_scripts or introduce_broker_match. It also gives clear guidance on when to use bUserId vs bLeadId, and warns against using it as a 'try it out' action because it marks leads as worked=true. This is strong when-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?

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?

The description goes far beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false) by disclosing concrete behaviors: partial failure without rollback, per-task push notifications, assigneeId defaults to self, and per-item failure for non-members. It also warns against treating the operation as atomic, which is critical for correct use.

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 compact labeled sections (需要登录/何时用/组合链/口径/坑), each carrying a distinct behavioral fact or workflow instruction. There is no filler, and the trigger condition is front-loaded in the second line.

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 non-idempotent, side-effecting batch tool with no output schema, the description fully covers the workflow (preview→confirm→落库→verify via get_collaboration_goal), failure modes, notification side effects, and preconditions. Nothing an agent needs to call it safely is missing.

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

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

Schema description coverage is 67%; the description compensates by explaining assigneeId omission (assign to self), preview=true semantics (real precheck), and the per-task push consequence embedded in the tasks item description. goalId is not explicitly explained but is a self-evident identifier from the parameter name and sibling 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 states a specific verb ('派', dispatch) and resource ('任务进同一个目标', tasks into the same goal), and explicitly contrasts with the App's single-dispatch limit approximating the singular sibling create_collaboration_task. The scope (max 10, same goal) is unambiguous.

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

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

An explicit '何时用' (when to use) section names the trigger: user gives several tasks at once. It also identifies the alternative for non-collaborators (invite_collaboration_member) and notes the singular App path only dispatches one at a time. The combination chain additionally prescribes the correct order of 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?

在 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 already indicate this is not read-only and not destructive, and the description adds meaningful behavior: the share is revocable and time-limited, the private plan stays private, and link holders can read content and express interest after phone verification. This gives the agent a clear picture of side effects.

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

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

Three short sentences, each adding distinct value: the creation condition, the privacy guarantee, and the reader-side behavior. The description is dense but contains no filler and is front-loaded with the critical usage gate.

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 the decision condition, expiry, privacy, and reader behavior, which is strong for a tool with only two simple parameters. It falls slightly short because there is no output schema and the description does not state what the tool returns, such as a share link or share ID, nor does it clarify what 'frozen' means.

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 clarify expiresInDays with range and default, and planId is strongly implied by the cooperation-plan context. However, planId itself is never explicitly described, so the description only partially compensates for the missing 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?

States exactly what it creates: a read-only, revocable, expiring share link for a cooperation plan. It also distinguishes this from making the private plan public, making the tool's scope and boundary clear.

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 to create the share only when the user explicitly requests a public link, and reminds the agent to confirm content suitability before creating. It does not name alternative sibling tools such as preview_cooperation_share or revoke_cooperation_share, so it stops short of full when-not/alternatives 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 (openWorldHint, idempotentHint=false), the description discloses concrete side effects: '这是公开动作，发布即进需求信息流', '没有请求去重，连调两次就是信息流里两条招募帖', and '发之前把 title/detail 原文念给用户确认'. These are critical behavioral traits not captured anywhere else.

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 longer than average but uses clear section markers (【需要登录】【何时用】【组合链】【口径/坑】) that make it scannable. Every section earns its place, but some redundancy exists (e.g., type default appears in both schema description and the text).

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

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

For a mutating tool with no output schema and significant side effects, this description covers all necessary context: preconditions (login), public visibility, dedup risk, confirmation requirement, type restriction, and alternative routing. An agent has everything it needs to invoke correctly and to warn the user.

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 covers 75% of parameters with descriptions; the description adds important extra semantics: '不传 type 默认 COLLAB（合作）；GIG 是兼职，语义不同别乱挑' and reminds that title/detail are user-facing ('原文'). The only gap is goalId, but its meaning is self-evident from the tool name.

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 its trigger ('目标缺人时'). It explicitly distinguishes itself from the sibling tool create_need by saying '挂在产品/活动/人上的需求走 create_need，不走这里', which clears up ambiguity.

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

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

The '【何时用】' section tells exactly when to use this tool and adds '任何合作人都能发，不必回头找发起人'. It also names the alternative create_need with an explicit condition for when NOT to use this tool. The '组合链' provides a complete downstream 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?

Annotations already declare readOnly=false, openWorld=true, idempotent=false, and destructive=false. The description adds substantial context beyond them: organizer login requirement, link-as-secret 14-day validity, non-idempotent behavior (each call creates a new card while old cards remain valid), and the public-session restriction. This is rich 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 front-loaded with the required context and purpose, then organized into clear sections for the workflow chain and caveats. Every sentence carries actionable information, with no filler or repetition.

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

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

For a create/mint operation with no output schema, the description covers prerequisites, parameter sourcing, downstream delivery steps, security constraints, validity duration, idempotency behavior, and eligibility restrictions. An agent has enough information to invoke it correctly and handle the result appropriately.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds the source of guestId via list_activity_guests/add_activity_guest, but does not add syntax or format meaning beyond the schema for activityRef. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description names a specific verb and resource: minting a self-service invite link for a guest in the lineup, with concrete capabilities (confirm attendance, edit title/topic, upload avatar/PPT). It distinguishes this from adjacent actions by explaining the guest-facing link and the surrounding chain, so an agent can identify it 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?

It explicitly states the required role and login context, the full workflow (list_activity_guests/add_activity_guest → this tool → send_message/start_conversation), and key conditions: only public sessions can mint, the link is 14-day valid and must go only to the guest. These are clear when-to-use and when-not-to-share constraints.

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 substantial behavioral context beyond the annotations: requires login and organizer role, the link itself is a secret key, repeated calls reuse the unexpired link and do not invalidate previously sent links, and non-public sessions will be rejected with the reason in the response. This is exactly the kind of disclosure that helps an agent invoke the tool safely and correctly.

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 headers for login requirement, when to use, combination chain, and behavioral rules. It is dense but every sentence carries useful information, and the most important decision guidance is front-loaded. 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?

For a one-parameter tool with no output schema, the description covers almost everything needed: auth, use case, prerequisite check, security, idempotence, and rejection conditions. The only minor gap is that the success return payload is not explicitly described, though the description strongly implies a URL is returned. This is a small omission given the otherwise thorough context.

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

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

There is only one parameter, activityRef, and the input schema already documents it as an activity slug or id with sources from list_my_activities and get_organizer_activity. Since schema description coverage is 100%, the description does not need to add much. It provides useful surrounding context about public events and reuse, but no additional parameter-level meaning.

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

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

The description states a clear verb and resource: create a self-recommendation link for external guests when no suitable internal candidate is found. It also distinguishes itself from get_activity_invites by saying to reuse an existing openInvite URL instead of recreating. This gives the agent a precise understanding of what the tool does and how it differs from related 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?

Usage conditions are explicit: use when internal candidates are insufficient, and the link is meant to be forwarded to a group so people can self-nominate. It also gives a concrete combination chain: call get_activity_invites first, and if an openInvite already exists, use its URL rather than calling this tool. The restriction that only public events can create the link is clearly 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?

Beyond the annotations, the description discloses multiple important behaviors: the need is public, appears in the feed immediately ('先过后审'), passes through asynchronous risk control, and triggers automatic vector matching and push to suitable principals. It also warns that publishing is a public action and requires user confirmation before posting. This adds substantial context without contradicting the readOnlyHint=false and openWorldHint=true 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 three labeled sections (【需要登录】【写好它】【挂载】), which makes it scannable and front-loads the most critical facts: authentication, immediate visibility, and public-action confirmation. Every sentence carries actionable content, and the examples are concrete and useful without padding.

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

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

For a six-parameter mutation tool with no output schema, the description covers all essential calling concerns: login requirement, side effects, moderation behavior, post-publish matching, content quality guidance, mounting semantics, and image preprocessing. The absence of a return-value description is a minor gap, but the overall operational picture is complete enough for an agent 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?

Since schema coverage is 100%, the baseline is 3, but the description adds real value beyond the schema: it explains title quality expectations (3–120 characters), notes that detail specificity improves matching/search, clarifies that contextType and contextId must be passed as a pair, and instructs using upload_image_from_url for stable image URLs. This is meaningful guidance, though it does not add much for the type parameter beyond what the enum already provides.

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

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

The description opens with '以当前用户身份发布一条需求' and positions it as '需求互换核心 loop 的起点', making the verb, resource, and scope explicit. It also differentiates from the sibling create_goal_recruit_need by noting the dedicated goal-recruitment entry, and references get_need_recommendations as a follow-up rather than a publishing 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 clearly states when to use this tool (publishing a need for the current user) and gives explicit routing: for goal recruitment it points to create_goal_recruit_need ('另有 create_goal_recruit_need 专用口'), and for images it says to first use upload_image_from_url. It also suggests get_need_recommendations as the follow-up for seeing matches, providing sequencing and alternative 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?

Annotations already declare write, non-idempotent, open-world behavior, but the description adds crucial context beyond them: immediate external visibility (post-review), private visibility must be explicitly passed, terms agreement enforcement, and a rate limit of about one per hour. 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?

Well-structured with labeled sections (【需要登录】【组合链】【口径/坑】) and front-loaded key information. Every sentence serves a purpose, though the pitfalls section is moderately long and could be slightly tighter.

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

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

Without an output schema, the description would ideally mention return values, but it covers auth, defaults, side effects, next-step chain, and rate limits. For a create tool with rich schema and annotations, it is largely complete.

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

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

Schema description coverage is 100%, so the schema already documents all parameters including enums and nested objects. The description reinforces visibility=PRIVATE and terms optionality, but adds little meaning beyond the schema; baseline 3 is appropriate.

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

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

States a specific verb and resource: '以用户本人名义建组织' (create an organization in the user's own name), lists example types (商会/社群/俱乐部), and clarifies the user becomes OWNER. It does not explicitly differentiate from siblings like create_company, but the resource is unambiguous.

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

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

Provides clear context: login required, defaults (public discoverable, join requires review), a combination chain for next steps (set logo, search candidates, invite members), and a confirmation requirement before creating. It lacks explicit when-not or alternative tool guidance, but the usage situation is well framed.

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 cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false). The description goes well beyond by disclosing the login requirement, the OWNER/ADMIN role gate, the failure mode organization_forbidden and its cause, and where the assignee sees the task — none of which structured fields provide.

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 bracketed blocks (auth, chain, pitfalls) are front-loaded and each sentence carries operational value. Slightly dense with some repetition of the timezone format, but 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 still tells the agent who can call it, what the assignee will see, and how to continue the workflow. It omits only the concrete response shape and whether duplicate pending tasks are rejected (idempotentHint=false is asserted but not explained).

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, but the description adds a genuine disambiguation: assigneeId is a userId, NOT a membershipId, which the schema does not state. It also restates the timezone-aware ISO requirement for dueAt, which the schema already covers.

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 (新建一条任务 in 组织) plus the assignment target (指派给一位在册成员), and the scoping to the organization space distinguishes it from the sibling create_collaboration_task/create_task_series. An agent can select it without opening the schema.

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

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

The 【组合链】 section names the prerequisite tool (list_organization_members), the exact field to carry over (user.id), a user-confirmation step, and the follow-up tools for progress and status (list_my_organization_tasks / set_organization_task_status). Explicit when-to-use and routing to siblings.

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

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

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 only indicate mutating, open-world, non-idempotent, non-destructive behavior. The description adds valuable context beyond that: login is required, moderation is post-publish (immediate public visibility), and slug collisions auto-generate a derived address. 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?

Three compact sentences with zero filler. The most decision-relevant facts (login, immediate visibility, moderation model) are front-loaded, followed by slug behavior and the next-step routing. 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?

For a 9-parameter create tool with no output schema, the description covers the essentials: auth requirement, publication timing and moderation, slug fallback behavior, and the recommended follow-up tool. It doesn't mention what the response contains (e.g., created product ID), but the update_my_product routing partially compensates.

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 44%, so the description needs to compensate. It does add meaningful nuance for slug (optional, server-generated, fallback when occupied) and frames links/media/tags as things that can be added later. However, it leaves tags, logoUrl, coverUrl, and the link visibility defaults unexplained, and the 9-parameter schema carries most of 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 uses a specific verb and resource ('新建一个产品 / 作品') and states the defining behavior: 先过后审, immediately visible after creation. It also names a sibling (update_my_product) for the continuation step, making the tool's unique role clear among close siblings like claim_product, set_product_status, and classify_product_draft.

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 routes the agent to update_my_product after creation ('创建后可用 update_my_product 继续补充链接 / 媒体 / 标签'), which is clear context for the creation-then-enrichment workflow. It doesn't explicitly state when not to use this tool (e.g., when a product already exists and should be claimed), so it's not a full 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?

Beyond the annotations, it reveals login requirements, platform restrictions, WEEKLY/MONTHLY parameter coupling, date-as-day semantics in Beijing time, assigneeId must be an existing collaborator and notification behavior, and the meaning of the generated return value plus auto-fill on later reads. This is substantial context that 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 compact and densely organized: three labeled sections ('何时用', '组合链', '口径/坑') with bulleted pitfalls. Every sentence carries operational value and the most important routing and caveats 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 9-parameter mutating tool with no output schema, it covers auth, platform limitations, required relationships, date/time semantics, frequency-specific constraints, response meaning (generated count), and future behavior. The lifecycle chain also tells the agent what to call next, which is more than sufficient context.

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

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

Schema coverage is only 22%, so the description bears the burden of explaining parameters, and it does so for the non-obvious ones: weekday must accompany WEEKLY (1=Mon...7=Sun), monthday must accompany MONTHLY with overflow clamped to month end, assigneeId must be a target collaborator or omitted for self, and dates are day-level YYYY-MM-DD Beijing time. This adds real meaning beyond raw schema types.

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 and resource: build a recurring-task rule that automatically generates future instances for long-term cadences like '每周一对齐一次'. It distinguishes from lifecycle siblings by naming update_task_series and stop_task_series for later modification/termination, and clarifies that only web/pro can create, so it is not a generic task-creation endpoint.

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?

An explicit '何时用' section gives the trigger condition (long-term recurring cadence) and platform constraint (web/pro only, App read-only). It also gives a recommended chain: create → verify with get_collaboration_goal(include:['series']) → later update/stop. It does not explicitly state when to use a one-off task sibling (e.g., create_collaboration_task) instead, so the routing is not fully 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 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?

虽然注解已声明destructiveHint=true和readOnlyHint=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，描述涵盖了所有关键行为：需要登录、永久删除、不可恢复、需用户确认、限制条件（归因已落袋不可删）、替代方案（update_broker_lead归档）。对于代理正确调用和规避风险来说，信息已足够完整。

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?

只有一个参数leadId，schema描述为“线索 id”已覆盖100%，描述没有额外解释参数含义或格式。按照规则，schema覆盖率>80%时基线为3，描述未添加新信息，因此保持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?

描述明确说明了动词（永久删除）、资源（一条线索），并限定只做单条、不开批量，与兄弟工具update_broker_lead（用于更新/归档）形成鲜明区分。开头的“永久删除”直接点出核心动作，没有歧义。

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_broker_lead(patch={archived:true})。还说明了在“归因已落袋”的情况下服务端会拒绝，为用户提供了清晰的预期和排除条件。

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 destructiveHint=true and readOnlyHint=false. The description adds valuable context: it removes homepage display and recommendations, and retains sent requests and history. This goes beyond the annotations by explaining specific consequences and what is not affected, improving the agent's understanding of the operation's impact.

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

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

The description is two sentences, front-loaded with the core action and effects. Every clause adds value, and there is no redundant information. It efficiently conveys the essential details without fluff.

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

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

The tool is simple (one parameter, no output schema), and the description covers the main behavior and when to call it. However, it fails to describe the 'id' parameter, which is essential for correct invocation. Without that, an agent may not know what to pass. The description is adequate for the operation's high-level behavior but incomplete for parameter usage.

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

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

The description does not explain the 'id' parameter at all. Schema coverage is 0%, so the description must compensate, but it provides no information about what the id represents or any constraints. An agent is left to infer that it is the plan identifier, but this is not explicit. This is a significant gap for a required parameter.

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

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

The description clearly states the tool deletes the user's own cooperation plan, removes it from homepage and recommendations, and retains sent requests and history. It uses a specific verb (delete) and resource (cooperation plan), and distinguishes from siblings like delete_need and unpublish_need by specifying the resource and scope. The condition '仅当用户要求删除时调用' adds a precise trigger.

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 call: only when the user requests deletion. It also clarifies what is preserved (sent requests, history), helping an agent understand the side effects. However, it does not mention alternatives like editing or unpublishing the plan, which would strengthen routing. Still, the primary usage condition is clear.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, yet the description adds genuinely new context: login is required, the deletion cascades to comments and likes, and it is 不可恢复 (irreversible). Those behavioral facts are not derivable from the annotations alone.

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

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

Two bracketed, front-loaded blocks with zero filler: one for preconditions/effects, one for the tool chain. Every clause carries actionable information.

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

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

For a single-parameter destructive tool with no output schema, the description supplies the precondition (login), the side effects, the irreversibility, and the required preceding workflow. Nothing an agent needs to call 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?

Schema description coverage is 100% and the single momentId parameter is already documented in the schema, including which tools can supply the id. The description adds no syntax or format detail beyond that, 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?

States a specific verb+resource (删除我发的一条消息圈) and immediately names the cascade scope (comments and likes) plus the ownership constraint (只能删自己的). An agent can distinguish it from get_moment, comment_moment, and like_moment without opening any schema.

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

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

The 【组合链】 block explicitly routes the agent: call get_user_moments without userId, read the target to the user for confirmation, then invoke this tool. It also states the when-not condition (只能删自己的). It does not discuss alternative deletion paths, but the intended workflow 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 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?

Annotations already mark destructiveHint=true, but the description adds critical behavioral context: other collaborators immediately lose management rights over the activity after detachment, and the agent must confirm the activity name with the user before proceeding. It also discloses the constraint that an activity can be attached to at most one goal, which explains why goalId is not needed. This goes well 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 compact and well-structured with clear sections: when to use, chained workflow, and pitfalls. Every sentence carries meaningful information, and the most important caveat (confirm with user) is front-loaded in the pitfalls section.

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 the essential context: prerequisites, side effects, permission requirements, and parameter source. The agent has everything needed to invoke it correctly and safely.

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 schema already describes activityRef as 'activity slug or id'. The description adds the source of that value (from get_collaboration_goal(include:["activities"])), which is useful but not extensive. Since the schema already covers the parameter well, a 4 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 ('detach') and resource ('activity from goal'), and clarifies the semantics: the activity itself remains unchanged, only the membership is removed. It also distinguishes itself from the sibling attach_activity_to_goal by describing the inverse operation.

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 it ('this activity no longer belongs to this goal'), provides a chained workflow (get_collaboration_goal → this tool), and gives clear exclusions: only the activity host can detach, and only activityRef is accepted. This is strong guidance for an agent.

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?

Despite annotations already marking destructiveHint=true and readOnlyHint=false, the description adds material behavioral context: the operation is irreversible ('不可撤销'), requires user confirmation before calling, and fails for already-claimed records with organization_import_claim_unavailable. It also explains the login requirement and the semantic meaning of the ignore 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 organized into labelled sections; the most critical warning (irreversible, ask user) is front-loaded with bold markers. Every sentence adds useful operational or semantic 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 single-parameter mutation with no output schema, the description covers prerequisites (login), policy constraints (ask user, irreversibility), workflow placement, and the known error condition. Nothing an agent needs to decide when and how to call 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?

Schema coverage is 100% and contactId is already described as '待认领资料 id', so the schema carries the meaning. The description reinforces the connection to the pending-claim list but does not add new parameter-level 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 first line states a specific verb ('标记为忽略') and resource ('待认领资料'), and defines the intent in parentheses ('不是我 / 不想被这个组织收录'). The combo chain explicitly contrasts it with claim_organization_profile, so an agent can distinguish ignore from claim without opening the schema.

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

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

The 【组合链】 section gives an explicit workflow: call list_my_organization_claims, wait for user confirmation, call this tool, then claim_organization_profile for remaining items. It also warns to ask the user first, and names the failing case 'already claimed' with its error code.

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 state not read-only, not idempotent, not destructive. The description adds substantial behavioral detail: draft must retain user-selected purpose and targetUserId, GENERAL avoids using entry-object identity, TARGETED revolves around target, preview-confirm before saving, advisor won't re-ask the target, references require user confirmation before inclusion, and recommendations are not auto-linked, saved, public, or sent. This goes well beyond 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 contributes a distinct operational rule or constraint. It front-loads the main purpose and then adds behavioral and usage conditions; there is no filler or repetition.

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

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

The description covers the central workflow: drafting/modifying, intent changes, context passing, preview-before-save, return shape (brief reply, one key question, suggestedReferences), and reference confirmation. It omits details about history and some draft fields, but given the tool's complexity and the agent-driven nature, it is sufficiently complete for correct invocation.

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

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

With 0% schema description coverage, the description compensates by explaining intent (REFINE vs ADAPT_PURPOSE), context fields (entryPoint, peerId, conversationId), and key draft constraints (purpose, targetUserId). It does not explain history or the full set of draft subfields, but those are largely inferable from names and types, and the most critical parameters are covered.

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 drafts or modifies a cooperation plan based on user facts, and adds scope constraints (preserving purpose and targetUserId, GENERAL vs TARGETED behavior). It does not explicitly name sibling tools like save_cooperation_plan or confirm_cooperation_version, so it falls short of full differentiation but remains unambiguous.

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

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

The description provides concrete when-to-use guidance: pass intent=ADAPT_PURPOSE for old drafts or purpose changes, and include context entryPoint/peerId/conversationId when an object was selected from profile or chat. It does not compare against alternative tools, but the within-tool usage conditions are 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?

Even with annotations marking destructiveHint and idempotentHint, the description adds concrete behavioral teeth: the viewer room closes immediately, the action cannot be undone, repeated calls are silent no-ops, and hasRecord=false at close time is not evidence of recording failure. 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 compact, sectioned with clear labels (需要登录/何时用/组合链/口径/坑), and every clause carries operational value. No filler or redundant restatement 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?

Despite having no output schema, the description covers login, when to invoke, the prerequisite confirmation, the composition chain, irreversibility, idempotence, and post-close recording semantics. An agent has everything needed to decide and call it correctly.

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

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

Schema coverage is 100% and both parameters already carry clear provenance descriptions (liveId from get_organizer_live; activityRef from get_activity/get_signup_activity). The description restates the chain but adds little semantic value 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's opening '何时用' plus '收场' and '结束这场直播' makes clear this tool permanently ends an organizer's live session. The chain references get_organizer_live and contrasts with the obvious sibling start_live_session, so an agent can distinguish it without opening schemas.

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 it ('播完了，主持人人在现场手上没电脑'), the mandatory user-confirmation precondition, and the recommended chain (get_organizer_live → this tool → later re-read for hasRecord). The '播完了' condition also implies not to use it while the live is still intended to continue.

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?

Discloses key behavioral traits beyond annotations: creating always flips on online participation (created=true → onlineEnabledNowOn=true), existing sessions cause no changes, liveId=null is not a failure and must not be retried, and only self-run/organization activities can create sessions. This is exactly the kind of side-effect and edge-case context that annotations do not carry.

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 efficiently structured with labeled sections (when to use, chain, pitfalls), and all sentences carry actionable information. Front-loading the login requirement and use case helps an agent quickly decide whether to invoke it.

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 explains return semantics (created flag, liveId null), side effects on onlineEnabled, prerequisites (login, activity type constraints), and relevant link behavior. An agent has enough context to call correctly and avoid retry mistakes.

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% for activityRef, so baseline 3 applies. The description does not add parameter-format detail beyond the schema, but it does not need to because the schema already explains slug or id and references get_activity/get_signup_activity.

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 action: create an activity live session idempotently, returning existing session when one already exists. This distinguishes it from siblings like start_live_session, which actually starts a broadcast, and get_organizer_live, which only reads state. Title also reinforces the organizer and idempotency.

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 when to use it ('主办方说这场我要开直播'), and gives a combination chain routing to get_organizer_live, the /pro page for stream credentials, and start_live_session as fallback. It also directs when the session already exists and when update_organizer_ticketing should be used instead, providing clear 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds substantial behavior beyond those: login requirement, the audience-gate (not signup) rule, that hidden/mutual-block messages are excluded (so results are not 'full'), pagination semantics (default 1000/max 2000, reachingLimit flag, nextSinceOffsetMs continuation), and the deliberate absence of a send capability. This is exactly the kind of non-obvious behavior an agent needs.

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 and longer than average, but every section earns its place: 何时用 (purpose), 组合链 (chain), 口径/坑 (numbered pitfalls). Information is front-loaded with purpose before details, and numbered bullets aid scanning. The length is justified given the number of non-obvious pitfalls (pagination, access gate, data completeness), though it could be slightly trimmed.

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

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

There is no output schema, so the description must carry the return-format burden. It covers login, access gates, data-completeness caveats, ordering, pagination, and read-only nature, and hints at the response shape via reachingLimit and nextSinceOffsetMs. The return object's fields are not fully enumerated, which is the main gap for a tool this complex.

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: kind=QUESTION filters and sorts by offsetMs ascending, liveId provenance (from get_organizer_live), and sinceOffsetMs used for pagination continuation. It reinforces limit's default/max and ties it to the reachingLimit/nextSinceOffsetMs behavior, enriching the bare schema entries.

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 concrete use case ('把这场的观众提问整理成纪要 / 看大家在哪一分钟最热闹'), states the verb and resource (export live interaction timeline), and clarifies that kind=QUESTION yields an ordered, analyzable time series. It names its position in a composition chain (list_my_activity_history → get_activity → this tool), distinguishing it from nearby 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?

Explicitly states when to use ('场后要...'), and explicitly states when NOT to: '撞 404 时 join_activity_online 帮不上忙...别调' and '本域刻意不提供代发弹幕/提问'. The access-gate rule (public vs non-public activities) further clarifies eligibility. Alternatives and exclusions are named directly.

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.