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

Annotations declare readOnlyHint=false, idempotentHint=true, destructiveHint=false; the description adds substantial non-redundant context: login requirement, the SMS-stopping side effect, the no-inference rule, the no-proxy-confirmation rule, and the nuance that confirming in the first three days does not cancel the prior day's reminder. It stops short of describing the return/pagination, but for a one-parameter confirmation tool that is minor.

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

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

Front-loaded with the login prerequisite and the trigger phrase, then the action, then the exclusions. Every clause carries a rule, but the run-on exclusion list makes it dense; it is efficient rather than wasteful.

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, yet the description covers auth, trigger, side effect, ambiguity handling, and scope boundaries for a single-parameter tool. Nothing an agent needs to call this 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 coverage is 100% and the single schema description already explains reminderId's origin, so the baseline would be 3. The description earns a bump by adding the disambiguation protocol — derive reminderId from the chat reminder, and ask rather than guess when multiple activities or the reference is unclear.

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 (confirm/acknowledge) and resource (the reminder round), plus the concrete side effect: stopping that round's follow-up SMS. It also explicitly delimits scope against adjacent actions (signup, attendance, cancellation, check-in), so an agent can separate it from siblings like respond_activity_invitation or cancel_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?

Gives an explicit trigger (the user themselves says '知道了'/'收到提醒了'/'我记住这场活动了'), explicit non-triggers (cannot infer from read state, inquiries, or system notifications), and explicit when-not-to-act rules (never batch, ask first if multiple or ambiguous, cannot act for others). This is about as opinionated as guidance gets.

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 destructive=true, idempotent=false and openWorld=true, and the description adds real substance on top: login/organizer authorization requirement, the preview-vs-confirm gate, requestId retry semantics that prevent accidental re-draws, and the irreversible nature of complete (seed published, cannot reopen). Disclosure of the previewHash/consent safety gate 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?

Front-loaded with the action enumeration, then the workflow constraints, with essentially no filler despite being dense. The packed clause-per-comma style is efficient but makes the gating rules harder to parse at a glance.

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 12-parameter destructive state machine with no output schema, the description covers the lifecycle, the preview/confirm flow, and the key preconditions. It omits the meaning of decision/reason, what lock does to existing tickets, and any return-value expectations, leaving minor but real gaps.

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

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

With 0% schema description coverage across 12 parameters the description must carry the load, and it mostly does: prizeId belongs to draw, drawId to review, claimCode to claim, evidenceReviewedByUser to review, and the consent/preview/previewHash triple to confirmation. It leaves decision (approve/reject) and reason unexplained, so the coverage is good but not complete.

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 concrete verb set and resource: the six raffle lifecycle actions (open/lock/draw/review/claim/complete) each with a one-word effect, so an agent knows exactly what the tool manipulates. It is clearly distinguishable in substance from get_activity_raffle and configure_activity_raffle, though it never names those siblings to route explicitly.

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

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

Gives per-action semantics plus explicit workflow rules: default is preview, confirmation requires same params + previewHash + consent=true + preview=false, retries must reuse requestId rather than re-drawing, review requires the user to personally see evidence, and claim requires a user-supplied claimCode. This is strong when-to-use context, but it does not address when to pick this tool over its raffle 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 declare the mutation/open-world profile; the description goes well beyond them by disclosing login+organizer requirement, the confirmed=false default and its public-page consequence, the ≤30 per-activity cap, that avatars are self-filled, and crucially that this tool sends no notification. These are exactly the side effects an agent needs before calling a write 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?

Front-loads the 【需要登录·主办方】 gating, then packs scope, defaults, limits, and the notification caveat into semicolon-delimited clauses with no filler. Dense but 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 non-idempotent write tool with no output schema, the description covers auth, side effects, limits, and non-notification behavior. The remaining gap is the return value (e.g. the created guestId), which would help a follow-up call but is minor for this operation.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters, including confirmed's intended meaning and userId's source. The description adds only the consequence of confirmed (default keeps the guest off the public page), a modest increment over structured data – baseline 3 is appropriate.

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

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

States a specific verb+resource (add a guest to the activity lineup) and immediately delimits scope: '只新增嘉宾' only adds, and existing guestIds must not be duplicated or re-stated. It also names a sibling (create_guest_invite_link) so the agent can distinguish add-vs-invite without opening either schema.

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

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

Clear when-to-use (new guest, on-platform vs external) and an explicit when-not ('已有guestId勿重复/改状态'), plus routing to create_guest_invite_link for the notification path. It stops short of naming update_guest_candidates as the tool for an existing guest, leaving one alternative implicit.

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

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

Beyond the annotations it discloses the ≤30MB fetch-to-private-storage limit, automatic image moderation (机审), the publish side effect that SLIDES/FILE broadcast to registrants, and the default visibility split (PHOTO=PUBLIC, others=REGISTERED). These are exactly the side effects and constraints 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?

The single dense paragraph is front-loaded with the auth/role constraint and every clause carries information (limits, moderation, side effects, defaults, follow-ups). It is terse rather than padded, though the semicolon-packed style mixes several topics without visual grouping.

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 5-parameter upload tool with no output schema, the description covers auth, limits, defaults, side effects, and follow-up tools, which is close to complete. It does not say what the call returns (e.g., a material id needed for later update/remove), leaving a small 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 coverage is 100%, so the baseline is 3; however the description adds default-value semantics for visibility (PHOTO defaults to PUBLIC, other kinds to REGISTERED) that the schema does not encode. It also advises confirming 'name' and visibility before publishing, which gives the two enum fields 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 names a specific verb and resource (upload one activity material by link) and scopes it to the organizer role with a login requirement. It also distinguishes itself from related siblings (list_activity_materials for verification, update_activity_material for rename/visibility), so an agent can route 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?

It states the precondition (login + organizer), the size constraint with a fallback ('大文件用/pro'), and explicitly routes rename/visibility changes to update_activity_material and verification to list_activity_materials. The '/pro' alternative is left opaque, which slightly weakens otherwise strong routing guidance.

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

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

Annotations 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 declare writability and non-idempotency, but the description adds material context beyond them: auth requirement, that the write is an append rather than destructive replacement, the per-type privacy defaults, the need to explicitly confirm public exposure of contact data, and the downstream audience ('公开内容可被get_creator看到'). This is exactly the extra behavioral surface an agent needs for a privacy-sensitive mutation.

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

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

Front-loads the login gate and the non-overwrite guarantee, then brackets the defaults and chain, so the highest-value facts come first. It is dense with little waste, though the visibility-default list largely restates the schema's own description of that parameter.

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-param mutation tool with no output schema, it covers auth, side effects, default derivation, exposure consequences, and follow-up calls. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is already 100%, so baseline is 3. The description reinforces parameter meaning by tying the visibility enum to type-specific defaults (phone=PRIVATE, IM apps=FRIENDS, others=PUBLIC) and stressing the explicit-public requirement, adding operational nuance beyond the 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?

Names a specific verb+resource (追加本人链接 = append own profile link) and adds the discriminating scope detail '不覆盖其余' (does not overwrite existing links), which cleanly separates it from sibling remove_profile_link and set_link_visibility. An agent can route correctly 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 clear context: login required, per-type default visibility, and an explicit conditional ('要公开联系方式必须显式传 public'). It also sketches a workflow chain (get_my_profile→添加→get_my_card). It stops short of naming set_link_visibility/remove_profile_link as the alternative for modifying or deleting an existing link, so guidance is strong but not exhaustive.

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

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

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?

Annotations already flag non-readOnly, destructive, openWorld, and non-idempotent behavior. The description adds important context beyond those flags: the confirmation requirement before submission, notification to the alliance manager, and the semantic that APPLIED means the organization has not yet joined, plus the possibility of switching alliances. It does not detail irreversibility or rate limits.

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

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

The description is a single dense but front-loaded paragraph: login and role requirements come first, followed by the workflow and final state semantics. Every clause carries operational weight, though the run-on structure is slightly less scannable than it could be.

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 with no output schema and existing safety annotations, the description covers prerequisites, confirmation workflow, manager notification, and post-submit state. It is nearly complete, missing only secondary details such as how to verify application status afterward or error-handling expectations.

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

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

Schema description coverage is only 25%; only grants has a schema description. The description implies organizationId is the organization relationship and allianceId is the target alliance, and clarifies that grants form a complete authorization list including required items, but it does not add format, length, or enum details sufficient to fully compensate for the low 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?

States a specific verb and resource: applying an organization to join an alliance, with login and role prerequisites. It distinguishes itself from siblings like apply_to_organization and submit_alliance_application by requiring organizationId and organization admin role, though it does not explicitly name those alternatives.

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

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

Explicitly states prerequisites (login required, must be organization actual responsible person/admin) and a workflow: read organization relationship and target alliance, enumerate grants to the user, confirm, submit, and notify the alliance manager. It does not name alternative tools for adjacent scenarios, so it is clear but not exhaustive.

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

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true) the description discloses login requirement, that the submission is genuinely created and admin-visible, the terms-acceptance gate, immediate admission via a 43-char invitationToken, and that existing members or PENDING applications return the existing record as a no-op rather than new progress.

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

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

Front-loaded with the login/real-submission constraint and no filler, but the middle is a dense semicolon-chained run of conditions that takes effort to parse. Efficient in length, less so in readability, though every clause carries real operational content.

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

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

With no output schema, the description compensates by describing result flags (joined=true, pendingReview=true, idempotent existing record) and the full pre-call workflow. The only real gap is the undocumented acceptContactSharing parameter for a tool with 6 params.

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 17%, so the description must carry the load and largely does: it explains termsVersionId/currentTerms.id, acceptTerms=true, the 43-character invitationToken, and the answers.key constraint. acceptContactSharing is never addressed in either the schema or the description, leaving one parameter opaque.

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 effect – a real organization-join submission that becomes admin-visible – rather than restating the name. It does not name a same-purpose sibling to separate itself from (e.g. preview_organization_invitation or apply_organization_to_alliance), though it does route onward to submit_signup after the apply step.

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

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

Explicit prerequisites and sequencing: call get_organization(includeTermsBody=true) to surface the agreement first, require the user's explicit consent before applying, include currentTerms.id plus acceptTerms=true only when an agreement exists, else omit both. It also states the invitationToken fast path, the idempotent behavior for existing/PENDING members, and that answers.key must come from formFields.

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, readOnlyHint=false, idempotentHint=false, openWorldHint=true, and the description does not contradict them. It adds substantial context beyond annotations: login requirement, that content is retained and owner-visible rather than erased, that edits republish, and that ownership/version drift causes rejection.

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

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

Front-loaded with the login requirement and scope, then the workflow, then the sibling alternative. Dense but each clause carries information; slight compression and punctuation-list style make it a touch harder to parse than optimal.

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 two-phase mutation with no output schema, the description covers auth, effect, retention, rejection conditions, and the confirmation flow. It omits only minor details (e.g., what the preview returns, failure surfaces), which is acceptable given the annotation coverage.

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

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

Schema description coverage is only 25% (only companyId documented), so the description must compensate. It explains the two-phase semantics of preview (default true), previewHash (from the preview step), and consent=true (required to execute), effectively documenting all four params beyond the bare schema.

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

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

States a specific verb+resource (下架本人公司主页) and immediately scopes it: stops public display/search, retains data, owner-visible. It explicitly distinguishes itself from update_my_company (republish on edit) and delete_my_company (permanent deletion), so an agent can route without opening other 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?

Gives an explicit, ordered workflow: call get_my_company first, default is preview, then confirm with same params + previewHash, consent=true, preview=false. It also names the alternative (delete_my_company) for permanent removal and the condition (ownership/version change) that causes rejection.

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

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

Goes well beyond the annotations by disclosing the key side effect: collaborators on the goal immediately gain management rights over the activity, plus an explicit authorization-scope warning and the login requirement. The non-idempotency implied by that grant is context the annotations alone (destructiveHint=false) do not convey. No contradiction with the declared hints.

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?

Very dense and front-loaded with the login gate and the side-effect warning ahead of the workflow steps. Every clause carries information, though the single run-on sentence with multiple semicolon clauses is slightly harder to parse than a clean multi-sentence layout.

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 mutation tool with no output schema, it covers auth, the permission-granting side effect, where to get the activity reference, a post-condition verification step, and the ownership constraint. Only goalId's expected format/meaning is left unexplained.

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

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

Schema coverage is 50%: activityRef is documented in the schema and the description usefully adds 'attachable' as an alternate source, but goalId is undocumented in both schema and description. The description adds some value for activityRef without fully compensating for the gap on goalId.

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 ('挂到' = attach) and resource ('本人活动' → '合作目标'), and its directionality immediately distinguishes it from the sibling detach_activity_from_goal. An agent can tell what this does 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 concrete workflow context: the activity reference is sourced from list_my_activities or 'attachable', and results should be verified with get_collaboration_goal afterward. It also states a clear when-not ('不能代挂他人活动'). It stops short of naming the reverse sibling (detach_activity_from_goal) as the alternative, so 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?

Annotations already carry destructiveHint=true and idempotentHint=false, but the description adds concrete consequence detail the annotations cannot: all 7 authorization items must be confirmed, staff auto-join, and switching alliances removes the old relationship, re-links access, and notifies the old alliance. This is meaningful disclosure of side effects beyond the safety flags.

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 paragraph that front-loads the login/permission requirement before the consequences and the recommended ordering. Every clause carries content, though the packing of prerequisites and effects into one block is slightly hard 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 destructive, non-idempotent mutation with no output schema, the description covers permissions, preconditions, side effects, notifications, and a recovery check. The one real gap is parameter meaning, which is left entirely to the undocumented schema.

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

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

Schema description coverage is 0% and neither param has any documented meaning, so the description carries the full burden. It only alludes to '目标联盟、组织' generically and gives no format, ID source, or validation semantics for allianceId/organizationId, so it does not compensate for the coverage 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 verb-resource pairing ('attach alliance organization' = 并入自有为联盟自有) is specific and separable from siblings like create_alliance_organization, detach_alliance_organization, and apply_organization_to_alliance. It fails to reach 5 only because '并入自有' is elliptical about what an attach actually changes without reading the rest of the sentence.

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?

Prerequisites are stated explicitly (login required, alliance manage permission, I must be the organization owner) and a workflow is prescribed ('先查双方详情，失败查实际关系'). It stops short of naming a sibling alternative for the when-not case, so it is clear context rather than full routing.

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

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

Beyond the destructiveHint/idempotentHint annotations, it discloses the concrete blast radius (all historical messages and pinned items hidden plus a broadcast), what is NOT destroyed (no account ban, other sessions untouched), field-level return semantics (hidden = true total, notified = broadcast count only, possibly capped at ~200), idempotency behavior (repeat keeps muted), and a retry-safety warning for unknown results. This is unusually rich behavioral context that goes well past what the annotations 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 single dense sentence is front-loaded with the gating requirement (login + organizer role) and packs requirement, scope, side effects, return meanings, and retry policy without filler. It is information-dense to the point of being slightly crowded, but no clause is wasted.

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

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

With no output schema, the description proactively explains the return counts (hidden vs notified) and their caveats, and it covers auth, scope boundaries, side effects, idempotency, and retry safety. An agent has everything needed to call this destructive 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 coverage is already 100%, so the baseline is 3. The description adds operational meaning on top of the schema: it instructs verifying targetUserId against the actual person at the host desk and confirming activity/session/scope, which sharpens how activityRef and liveId scoping should be applied in a destructive action.

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 (ban this user for the current live session) and immediately scopes it: mutes danmaku questions and hides all of the user's historical messages and pins in this session, with broadcast. It also rules out confusion with account-level bans, explicitly noting it does not ban the account or affect other sessions, distinguishing it from siblings like block_user or unban_live_user.

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 a clear precondition (login required, must be this session's organizer, verify targetUserId at the host desk) and explicit when-not guidance (do not arbitrarily batch, does not affect other sessions). It stops short of naming alternative sibling tools to use instead, so it is strong context without full alternative routing.

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

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

Annotations already declare idempotentHint=true, so the '重复拉黑 no-op' line partly restates structured data. However, the description adds value beyond the annotations by stating the login requirement and the concrete effects (mutual DM block plus automatic unfollow), which the annotations do not convey.

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

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

One compact line, front-loaded with the login precondition, then effects, then usage scenario, then idempotency. Every clause earns its place 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 the precondition (login), the behavioral effect, the intended scenario, and repeat-call behavior. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100% and there is only one parameter ('userId', documented as the user to block), so the schema already carries the parameter meaning. The description adds no syntax or format detail beyond it; 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?

States a specific verb and resource ('拉黑某用户') and immediately names the exact consequences (mutual DM disabled, auto-unfollow), which distinguishes it from siblings like unblock_user, ban_live_user, and report_content. An agent can identify the operation 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 a clear scenario trigger ('处理骚扰时用' – use when handling harassment), which is real usage context. It does not name an alternative or exclusion (e.g., report_content vs. block), so it stops short of full when/when-not routing.

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

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

Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds substantial context: the effect is a real, irreversible push ('收不回'), processing is serial, partial failures must be diagnosed individually, and it documents two error paths (organization_application_resolved for conflicting prior review, organization_rate_limited with retry-after).

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

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

Front-loads the auth/role gate and the 100-item cap, then uses an arrow flow for the sequence and terse clauses for edge cases. Dense but every clause carries operational meaning; 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 does the heavy lifting by describing success/failure reporting and specific error codes. It stops short of describing the exact return payload shape, but covers 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 the baseline is 3; the description still adds meaning by explaining that preview defaults to true and that execution requires an explicit preview=false, plus how the decision reasons should be surfaced to the user.

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 (bulk-review organization membership applications) with scope and role gating (OWNER/ADMIN, max 100). It distinguishes itself from the sibling list_organization_applications by naming that tool as the read-side counterpart it feeds from.

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 an explicit end-to-end workflow: list_organization_applications(pendingOnly=true) → preview → confirm → execute → report. It clearly states preview=true first to read names/reasons verbatim, then preview=false to actually act, leaving no ambiguity about when each mode is used.

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=false, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the description's main added value is the permission requirement (login + organizer), the immediate applicant-visible effect, the 200-id cap, the ignore behavior for out-of-scope ids, and the irreversibility of bulk-clearing notes. This sits between the lower bar for annotated tools and the top score, because the response fields are only named, not shaped, and there is no description of failure modes beyond ignored ids.

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?

Heavily front-loaded: permission gate first, then the workflow chain, then limits and reporting. Every sentence carries an operational constraint, though the bracketed inline notation packs three distinct topics into one block and the clause 「余者换reviewStatus另处理」 is terse to the point of ambiguity.

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 report fields (requested/updated/ignoredIds). Combined with the preview protocol, the 200-id limit, the permission requirement and the note-clearing prohibition, an agent has everything needed to call this safely on the first attempt.

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

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

Schema coverage is 100%, so the parameter baseline is 3. The description adds value the schema lacks: preview is framed as a mandatory confirmation gate rather than an optional flag, ids belonging to other activities are silently ignored rather than erroring, and reviewNote omission means leaving each person's existing note untouched, whereas an empty string is rejected.

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+scope: batch-change signup review results, explicitly not the delivery state (「不改投递态」). This distinguishes it from the single-submission sibling review_signup_submission and from status-agnostic list tools without needing to name them.

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

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

Gives an explicit chain: fetch ids via list_signup_submissions → run with preview=true (no persistence) → get user confirmation of the id/nickname/current-state list → run with preview=false. It also states the exclusion that other applicants must be handled by a different reviewStatus pass, and that confirmation cannot be skipped.

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, idempotentHint and openWorldHint, so the safety profile is covered. The description goes beyond them by stating the login requirement and the terminal-state rule (cannot cancel an already cancelled/ended activity), both of which are actionable behavioral facts not in the structured 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?

Two short sentences with the auth prerequisite front-loaded and no filler. Every clause (login requirement, action, state constraint) earns its place, though there is little room to demonstrate structure.

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

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

For a single-parameter cancel tool with annotations covering safety and no output schema to explain, the description supplies the missing pieces: auth need, scope, and the state precondition. An agent has enough to call it correctly, though naming the sibling it is not would fully close the 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 coverage is 100% and there is a single parameter, so the schema already documents activityId fully. The description adds no syntax, format, or meaning beyond that, making the baseline 3 correct.

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 plus scope: cancel (take offline) an activity I initiated. The modifier '我发起的' implicitly disambiguates from the sibling cancel_my_activity_signup, which cancels a signup rather than a hosted activity, giving real sibling separation.

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 a precondition (already-cancelled or already-ended activities cannot be re-cancelled), which is genuine usage context, but never names an alternative tool or explains when to prefer this over e.g. cancel_my_activity_signup or update_activity. Guidance is implied rather than explicit.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation profile is known. The description adds substantive context beyond that: login is required, alliance 'manage' permission is needed, and the effect is limited to pending invitations without ejecting joined orgs.

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 with the auth requirement front-loaded and the scoping constraint appended. No filler, though the bracketed login tag and permission clause make it slightly dense.

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

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

For a 2-param destructive action with no output schema, it covers access prerequisites, the verification step, and the effect boundary. The main omission is a concrete explanation of the linkId/allianceId parameters.

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% for the two required params, so the description carries the burden. It references linkId by name (核实 linkId 与组织) and implies the organization context, but never explains what linkId identifies or how allianceId relates, leaving the compensation incomplete.

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

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

States a specific verb and resource (撤回联盟发出的加盟邀请 / withdraw an alliance invitation) and draws a clear boundary: it only cancels pending invitations and does not remove already-joined organizations. This distinguishes it from sibling mutators like detach_alliance_organization and remove_organization_member without needing their names.

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 precondition (【需要登录】須联盟 manage) and the negative scope (只取消待接受邀请，不移出已加盟组织), which tells the agent when NOT to reach for this tool. It stops short of naming a direct alternative to use for removal, but the routing context 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 non-idempotent, but the description adds substantial context beyond them: login required, initiator-only authorization, irreversibility, the side effect that the invite vanishes from the recipient's to-do list, and precondition checks before acting.

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 front-loaded: authorization and irreversibility come first, then ID sourcing, then the precondition branch. Every clause carries a distinct obligation, though the compact run-on style slightly reduces scannability.

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 the authorization model, the ID source, irreversibility, the precondition case, and the observable effect — everything an agent needs to call it correctly.

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

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

Schema coverage is 0%, so the schema alone gives no meaning to inviteId. The description compensates by telling the agent where to source it — get_collaboration_goal(include=invites) — which is exactly the missing guidance, though no format/validity detail (e.g. the 40-char bound) is conveyed.

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 — withdrawing a collaboration invitation — and immediately scopes it to 'unresponded invites by the target initiator'. This differentiates it cleanly from siblings like cancel_alliance_invitation and respond_collaboration_invite.

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

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

Explicit when-to-use rules: only the initiating party, only for invitations with no response yet, verify the recipient before confirming, and do not retry when the invite is already accepted/declined/expired — instead check current status. Nothing is left to inference.

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

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

Annotations already declare destructive=true and idempotent=false, but the description adds what the annotations cannot: a login requirement, a mandatory preview-then-confirm flow requiring an echo of previewHash with consent=true and preview=false, and precise blast-radius limits (no refunds, no ticket/pass/online-rights cancellation). This is exactly the behavioral context an agent needs before a destructive call.

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

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

Front-loads the login requirement and the trigger condition, then layers scope, confirmation workflow, and exclusions. Every clause is load-bearing for a destructive operation, but the density of semicolon-joined clauses makes it heavier than the tightest possible phrasing.

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 destructive mutation with no output schema, 0% schema coverage, and a multi-step confirmation protocol, the description supplies the login prerequisite, the two-phase call sequence, the non-reversible side-effect scope, and the fallback for ineligible cases. Nothing an agent needs to invoke this 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 0% across 4 params, so the description must carry the load — and it largely does, explaining how preview=true differs from preview=false, that consent must be true, and that previewHash must be echoed with identical parameters. The only gap is activityRef, whose format and source are never described, though its meaning is inferable from 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?

States a specific verb+resource (withdraw my own offline signup) and immediately narrows scope to '独行录本站线下报名和待激活占位', which distinguishes it from organizer-side siblings like cancel_activity and from invitation responses like respond_activity_invitation. An agent can identify the exact operation and its boundary 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?

Explicit trigger ('本人明确无法参会或要取消报名时用'), explicit exclusions ('不退款、不取消门票年票或线上观看权益；外部表单仍须主办方撤回'), an escalation path ('已签到或已开场须联系主办方'), and a disambiguation warning ('勿把取消提醒当取消报名'). This is a full when/when-not/alternatives statement.

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

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

Annotations already declare destructive=true, readOnly=false, and idempotent=false, so the safety profile is covered. The description adds real context beyond that: login requirement, that only the caller's own pending application can be affected, and that an established alliance is not removed — an important scope-of-destruction detail.

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

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

Front-loads the login requirement in brackets, then the core action, then the boundary conditions. Every clause carries distinct information with no redundancy.

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

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

For a one-parameter destructive action with no output schema, the definition covers auth, valid-state preconditions, and the negative boundary (approved/rejected, established alliance). Only the exact prior tool to read state is left implicit, which is a minor 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?

Single parameter with 0% schema description coverage, so the schema alone is silent. The description adds that the id must be 'confirmed' after reading one's own state, implying where the value comes from, but provides no format/identity details beyond the schema's string constraints. Modest compensation, hence baseline 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?

States a specific verb+resource (withdraw my own alliance application) and immediately constrains scope to '本人待审' (my own pending ones), which separates it from submit_alliance_application, cancel_alliance_invitation, and cancel_organization_alliance_request without needing their 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?

Gives an explicit precondition workflow ('先读本人状态并确认申请 id') and a clear exclusion ('已通过/驳回不能撤回'), so an agent knows when the call is valid and when it will fail. It stops short of naming the exact sibling tool to call first, but the conditional guidance is strong.

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, idempotentHint=true and readOnlyHint=false, but the description adds substantial context beyond them: a login prerequisite, the irreversible terminal state (no edit/reopen), and the exact error semantics (403 not_your_need, 409 need_already_completed, 409 need_closed). This is genuinely useful behavioral disclosure for an agent deciding whether to call or handle failures.

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-loaded with the login requirement and the most decision-relevant fact (terminal state), then the alternative tool, then error codes. Every clause carries information; the semicolon-chaining is compact though slightly crammed.

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 mutation with annotations present and no output schema, the description covers prerequisites, terminal-state behavior, alternative tooling, and failure modes. Little is missing for correct invocation.

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

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

Schema description coverage is 100% (needId '需求 id'), so the schema already documents the single parameter. The description adds no syntax or format detail for needId, 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?

States a specific verb+resource (cancel a need) and immediately distinguishes it from siblings: it is a terminal state, unlike the temporary unpublish_need, and implicitly from delete_need/complete_need/reopen_need. An agent can route correctly without opening any other 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?

Explicitly names the alternative (unpublish_need) and the condition that selects it (temporary takedown), plus states that this action is terminal and cannot be reopened. When-to-use vs. when-not is fully specified.

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 destructive, non-idempotent, open-world behavior; the description adds critical auth requirements (login, actual manager) and a scope limitation (pending only), which go beyond the annotations. It does not contradict them.

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

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

A single compact sentence front-loads prerequisites (login, manager role) then the action and its scope. No wasted words.

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 destructive mutation with no output schema and 0% parameter description coverage, the description covers auth and scope well but leaves the two required parameters inadequately explained. An agent could still call it, but would need to infer parameter meanings.

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

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

Schema coverage is 0% and neither parameter is described in the schema. The description only instructs confirming the organization's linkId via a prior read; it provides no meaning or format for organizationId and only vague context for linkId, leaving parameter semantics largely unaddressed.

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 (withdraw organization alliance application) and explicitly scopes it to pending applications only. This distinguishes it from sibling tools like leave_organization_alliance (exiting a joined alliance) and cancel_my_alliance_application (personal application).

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?

Specifies login requirement, actual manager role prerequisite, and a preparatory step (read alliance status and confirm linkId). Clearly states the tool only withdraws pending applications and does not exit joined alliances, though it does not name the alternative tool for exiting.

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 substantial behavior beyond the annotations: cancellation is explicitly not a refund (取消非退款), a payment/close race may already have paid (支付/关单并发可能已付), success must be judged from the returned status, and it closes the original order. This covers what gets destroyed, the auth requirement, and the success criterion, which the destructive/idempotent hints alone do not.

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?

Single dense sentence with semicolon-separated clauses; every clause carries real information and the login requirement is front-loaded. It is compact rather than bloated, though the run-on structure and reliance on domain shorthand reduce scannability slightly.

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, two-phase mutation with no output schema and 0% parameter documentation, it covers the workflow, auth needs, concurrency caveat and success criterion, and defers return-value interpretation to the returned status. Only the identifier parameter and edge-case failure handling are left unaddressed.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does: it explains preview as a mode flag (default preview) and previewHash as the value returned by preview that unlocks confirmation with preview=false. outTradeNo is left implicit, and no format/length hints are given, so it is not a full 5.

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: cancelling one's own unpaid payment order by closing the original order (关闭原单). The two-step preview/confirm nature is made explicit. However, it never names or contrasts with the obvious sibling resume_payment_order, so an agent must infer the distinction itself.

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

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

Gives clear context: login required, first call preview, then re-invoke with the same params plus previewHash and preview=false to actually close. No explicit when-not or alternative-tool routing (e.g., vs resume_payment_order) is provided, so it stops short of a 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive/open-world, so the safety profile is covered. The description adds value beyond them: it requires login, exposes the meaning of specific status codes, and importantly warns that organizer_profile_required needs App SMS verification which MCP cannot write — a real limitation an agent must know.

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?

Tightly packed: login requirement and purpose are front-loaded, followed by criteria and then an arrow-mapped error-code→action table. Every clause carries information, though the telegraphic notation is dense and slightly cryptic without domain familiarity.

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 conveys the failure codes and required remediations, which is the bulk of what the response carries. It does not explicitly describe the success-case payload, a minor gap for a zero-parameter gate.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline for a parameterless tool is 4; no misleading parameter claims are made.

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 (check eligibility to host an activity) and enumerates the exact criteria evaluated: host bio/intro ≥10 chars, published product, organizer onboarding with org/contact/phone/intro. An agent can distinguish this pre-flight gate from create_organizer_activity without opening either schema.

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

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

Explicitly says to run this before hosting (办活动先查) and then routes each outcome to the correct next tool: profile_incomplete→onboarding, no_published_product→create_product, all clear→create_organizer_activity. When-to-use, when-not, and alternatives are all named.

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

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

With annotations already declaring readOnlyHint=false, idempotentHint=true, destructiveHint=false, the description adds meaningful behavioral notes: does not produce a verified e-pass, does not write or group once App-only check-in is enabled, and result-per-item semantics (逐条返回结果, cannot call a failure 'attended'). It doesn't explicitly say the operation is idempotent or explain what 'not verified' means for downstream state, but the coverage is strong.

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

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

Front-loads the constraint and permission (需要登录·主办方, 仅兼容期) before edge cases, then limits and per-item result semantics. Dense but each sentence carries operational meaning; only the eligibility line ('每位都须完成资料并满足当前门票和受众资格') is slightly under-defined.

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/permission, timing constraint, batch size, eligibility, per-item results, and a redirect to get_activity_attendance. No output schema, so the description appropriately notes per-item result shape but could quantify failure cases or mention grouping behavior more precisely.

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 already documents both userIds (source: get_activity_attendance / list_signup_submissions) and activityRef (slug or id). The description reinforces the 50-user limit and the eligibility requirement, but adds little syntax beyond the schema. Baseline 3 is correct.

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 (人工补录 manual check-in / backfill) and resource (attendees, userIds) for hosts, and distinguishes itself from the App self-check-in flow. Sibling check_in_my_activity and get_activity_attendance are implicitly delimited by '本工具不再写入或分组' and '历史名单用 get_activity_attendance 查询', but the distinction is not spelled out as explicitly as a 5 would require.

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

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

Explicit when-to-use (仅兼容期) and when-not-to-use (活动开启 App 专属签到后必须本人在 App 签到), plus names an alternative for historical lookup (get_activity_attendance). This is textbook condition-based routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so safety is covered. The description adds genuinely new context: login is required, the call will not execute any check-in write, and legacy parameters are retained for compatibility but are no-ops.

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 login requirement and read-only nature are front-loaded in the first clause, followed by the App-only check-in flow and the legacy-parameter caveat. Each sentence carries information, though the density of constraints makes it slightly heavy for a status-read tool.

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

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

For a read-only tool with no output schema, the description covers the essentials an agent needs: authentication requirement, the fact that no write occurs, the App-only verification path, and the legacy-parameter caveat. 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 low (25%): only 'consent' is documented in the schema. The description hints that some parameters are legacy compatibility shims that won't perform writes, which adds partial meaning, but it does not explain preview, previewHash, or the required activityId semantics.

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

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

The description states a specific read-only verb and resource ('只读本人活动签到状态和 App 续接入口') and immediately clarifies that it does NOT perform the actual check-in write. This resolves the ambiguity created by the name 'check_in_my_activity' and separates it from write-oriented siblings like check_in_attendees.

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 when-not guidance: on-site check-in must be done by the user in the App via location or dynamic code, and Agent/web/mini-program do not check in on behalf; no auto signup or ticket purchase. It stops short of naming a specific sibling alternative tool to route to instead.

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

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

Adds substantial context beyond the annotations: the operation is irreversible, requires login, and returns ok=false with a specific error taxonomy (invalid/not_found/claimed/self) plus retry guidance. The only blemish is a mild tension between '不可逆' and destructiveHint=false, and it does not say what happens to the underlying placeholder owner's data or the exact auth identity required beyond 'login'.

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

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

Front-loaded with the login requirement and the core action, then brackets the error handling and workflow chain. Dense and mostly waste-free, though the bracketed shorthand and mixed encoding make it slightly harder to parse than plain prose.

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

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

For a two-param mutation with no output schema, the description covers the prerequisite, the irreversible effect, the partial response shape (ok=false cases), and the surrounding workflow. What is missing is what success returns and what permissions/identity the caller must hold beyond being logged in.

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%: token ('邮件链接 ?ct=<token>') and creatorId ('邮件链接 /u/<creatorId>') are both fully documented in the schema. The description only reinforces the email/token origin ('邮件ct token') and adds no format or validation detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb+resource ('不可逆认领整份占位主理人资料/产品/会话' by email ct token) and explicitly scopes it as NOT a single product code, which separates it from the sibling claim_product. An agent can tell what it does and how it differs from neighbouring claim tools 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?

Gives a hard prerequisite ('需要登录'), an explicit workflow chain (确认身份/token来源→认领→get_my_card), and a retry warning ('勿盲重试'). It differentiates from claim_product via '非单产品码', but does not spell out when to prefer it over claim_organization_profile or other claim routes, so it stops just short of full when/when-not coverage.

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 substantial behavior beyond annotations: login required, the claim is irreversible, values must be read back to the user for confirmation, insert-only semantics (existing canFill=false fields are untouched, so filledCount may be < fieldKeys length), the post-claim state change, and accept must be explicitly true. These are consistent with destructiveHint=true and idempotentHint=true, so 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?

Front-loaded with purpose and the login/irreversibility warning, then organized into labeled sections (组合链, 口径/坑) with no filler sentences. It is dense, but every clause carries operational 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 destructive, cross-form write tool with no output schema, the description still covers auth, irreversibility, the surrounding workflow, parameter requirements, and the shape of the outcome (filledCount vs fieldKeys length). Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is low (33%), so the description must compensate, and it does: contactId is the id from list_my_organization_claims, accept must be explicitly true, and fieldKeys is passed all-at-once with insert-only behavior relative to canFill. It does not spell out individual enum field meanings or the maxItems=11, leaving a small 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 states a specific verb+resource: claim a to-be-claimed profile and one-shot backfill the selected fields into the signup profile layer (cross-form reuse). It also draws the boundary against the sibling list_my_organization_claims, which supplies the id/fields, so an agent can tell the two 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 【组合链】 block gives an explicit workflow: list_my_organization_claims → this tool's fieldKeys (all at once) → get_signup_gaps → submit_signup, which clearly positions when to call it. It stops short of an explicit when-not-to-use or exclusion, so it is clear context rather than a full rule set.

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 the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description adds behavior annotations do not: it is login-gated, it publishes the product immediately upon claiming, and it passes first but is reviewed afterward. That immediate-publish side effect is the key non-obvious trait.

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 short, front-loaded block that leads with the login gate and side effect before the claim-code note; every clause carries information, though the parenthetical about admin/crawler pre-recorded products adds a little noise.

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 annotations present and no output schema, the description covers the prerequisites (login), the trigger (claim code), and the outcome (instant publish), leaving little an agent needs to know before calling it.

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 parameter claimCode is already described, so baseline is 3; the description goes slightly beyond by stating where the code comes from (admin-issued), giving the agent a hint about acceptable input provenance.

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 (产品), plus the mechanism (认领码), and distinguishes the target from sibling claims like claim_creator_by_token and claim_organization_profile by specifying it re-parents an admin/crawler pre-recorded product onto the current account.

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 useful invocation context — login required and that the claim code is usually issued by an admin — but never explicitly contrasts this tool with alternative claim paths, so the agent must infer when to pick it over claim_creator_by_token.

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 context beyond the annotations: it requires login, incurs real LLM cost, does not write to the DB, and may return null category/tags/domain with OTHER as a normal fallback. That is meaningful operational context an agent could not derive from the schema. Note a mild tension: it says '不写库' (no DB write) while readOnlyHint=false implies a non-read-only operation; this reads as conservative cost-based marking rather than a true 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 【需要登录】/【组合链】bracketed structure front-loads the login precondition and then the workflow, so the highest-priority facts come first. It is dense and jargon-heavy but nearly every clause carries distinct information (auth, cost, no-write, null/fallback, chain, anti-loop).

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 3-parameter tool with no output schema and rich annotations, the description supplies the missing pieces: auth requirement, cost, write behavior, null/fallback output semantics, and the surrounding workflow. An agent has enough to call it correctly and to know when not to repeat it.

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 100% schema description coverage, the schema already documents name, tagline, and description including defaults and length limits. The description adds no input-syntax detail; its 'category/tags/domain可null' remark concerns outputs, not inputs. Baseline 3 applies when the schema carries the parameter 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 states a specific verb+resource: an LLM-based classification of a product draft before publishing ('草稿发布前LLM分类'). It also distinguishes itself from siblings by noting that create_product/update_my_product perform their own auto-classification, so the agent knows this is the preview-only step. It is slightly cryptic due to terse abbreviations, but the purpose is unmistakable.

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

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

It gives an explicit workflow: classify → user verifies → create_product/update_my_product, and clarifies that the downstream tools auto-classify, which tells the agent when this call is redundant. The '勿循环试探' (don't loop-probe) warning further constrains usage. It stops short of stating an explicit when-not-to-use condition, keeping it from a 5.

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

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

Annotations already flag destructiveHint=true and idempotentHint=false, but the description adds auth requirements, the preview/confirm gate, the non-rollback guarantee ('后续失败不会回滚已下架/已停项'), and the skipped=not_your_need edge case. This is meaningful context well beyond the structured fields.

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 front-loaded: the auth/actor constraint leads, followed by cascade scope, the sibling distinction, the preview workflow, and the irreversibility caveat. Every clause carries unique information, though the run-on style makes it slightly hard 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?

No output schema exists, yet the description covers the preview result shape, the skipped indicator, irreversibility, and the non-cascading alternative. Nothing an agent needs to call this destructive cascade 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 coverage is 67% with enum and preview semantics already in the schema. The description goes further by explaining that preview=true yields concrete counts (N recruitments/M rules/K periods) and that preview=false must follow explicit confirmation, adding behavioral meaning to the preview 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?

States a specific verb+resource ('关闭目标' / close goal) plus the cascade effect (级联下架本人公开招募、停周期规则/待生成期次), and explicitly distinguishes itself from the sibling update_collaboration_goal by noting that one changes status without cascading. An agent can route correctly without opening either schema.

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

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

Specifies the required actor ('需登录·目标发起人' - logged-in goal initiator), prescribes the safe workflow (preview=true to see N recruitments/M rules/K periods, then explicit confirmation before preview=false), and routes the excluded case (others' recruitments skipped=not_your_need) to unpublish_need. Explicit when-to-use, when-not, and alternatives.

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

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

Annotations already declare mutation, idempotency, non-destructiveness, and open-world behavior, but the description adds substantial context: login requirement, archived-lead restoration, skipped self/unavailable accounts, anonymous-user skipping with reporting, and note/tags restrictions. No statement 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?

Front-loads the login requirement and core action, and each semicolon-separated clause carries operational detail. The dense single-block structure is efficient but slightly harder to scan than a clean multi-sentence layout.

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 prerequisites, mutation effect, idempotency, skipped-account handling, source filtering, and the next workflow step. It does not describe return values, but no output schema exists and the description is otherwise sufficient 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 descriptions already cover all 3 parameters at 100%, so the baseline is 3, but the description adds real semantic rules: note must not contain answer-sheet content, tags are only activity identifiers, and userIds come only from signup records that have a userId. This meaningfully supplements the schema, though it is not exhaustive.

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/scope: 收≤20站内用户入本人线索池, and names the follow-up scan_broker_matches. It does not explicitly contrast with close siblings such as create_broker_lead or import_broker_leads, so it falls short of full sibling differentiation.

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

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

Gives a clear prerequisite (需要登录) and a follow-up action (收完可scan_broker_matches), but does not state when-not to use it or compare it directly against alternatives like create_broker_lead. Usage is implied by the source constraint (报名单仅取有userId者) rather than explicitly guided.

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

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

Goes well beyond the annotations: it discloses that the author (and the replied-to person) receive a notification, that content is publicly visible, that login is required, and that the content must be confirmed with the user before sending. This is exactly the kind of side-effect and auth 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 bracketed sectioning (【需要登录】/【组合链】/【注意】) front-loads the action and keeps the chaining and safety notes scannable. It is dense but nearly every clause carries distinct information, with only minor overlap against 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 mutation tool with no output schema, it covers auth, side effects, visibility, input sourcing, and the confirmation requirement. The only gap is that it does not mention the return value or any rate limits, but nothing essential to 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 schema already documents momentId, content, and replyToCommentId. The description only restates the replyToCommentId meaning and repeats a length rule that actually conflicts with the schema (description says 1-500 chars, schema maxLength is 1000), so baseline 3 applies.

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

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

States a specific verb and resource ('以用户名义在一条消息圈下评论'), and explains the reply variant via replyToCommentId. An agent can immediately distinguish it from siblings like like_moment, publish_moment, or delete_my_moment.

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 names the upstream tools to get inputs (list_moments_feed / get_moment for momentId and commentId) and routes the reply-to-interaction case to list_moment_notices first. Prerequisites (login required) and the confirmation step are stated up front.

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?

Strong disclosure beyond the annotations: login requirement, the write-defaults-to-preview flow, the exact confirmation recipe (same params + previewHash + consent=true + preview=false), and the caveats that acceptance does not imply WeChat-group membership and venue confirmation does not imply payment. These are non-obvious behaviors an agent cannot infer from readOnlyHint=false and openWorldHint=true 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?

Dense but front-loaded, opening with the login requirement and organizing subsequent clauses by action with semicolons. Nearly every clause carries information, though the run-on density makes it slightly harder to parse than an ideally structured description.

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

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

For a 14-parameter multi-action tool with no output schema and only weak annotation coverage, the description supplies the key procedural knowledge: action routing, cursor strategy, and the preview/confirm safety protocol with its caveats. A few parameters (limit, note, status enum semantics) remain undocumented, keeping it just short of fully 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?

With 0% schema description coverage, the description must carry the load and largely does: it ties kind/box/status to pagination, groupCursor/venueCursor to mixed-list paging, requestId to get, and previewHash/consent/preview to the confirm step. It leaves limit, note, cursor, and the status enum values unexplained, so compensation is substantial but incomplete.

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

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

The description enumerates the three operations (list/get/respond) and the resource they act on (group/venue requests), so an agent knows this is a request-management tool. It does not, however, distinguish itself from any sibling such as manage_my_community_resource or contact_community_resource, so differentiation is left implicit.

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 per-action routing (list paginates by kind/box/status, mixed lists split across groupCursor/venueCursor, get reads requestId, respond uses accept/confirm/decline/cancel) and a genuine when-condition for organizer_confirm (only after offline negotiation). No alternative sibling tools are named, so it stops short of explicit when-to-use-this-vs-that 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?

Adds substantial context beyond annotations: the two-party confirmation semantics, the authorDone/claimerDone state fields, and precise non-retry conditions for 403/409. Neither the annotations nor schema convey any of this.

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

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

Front-loaded with the auth tag and core gating rule, then error codes, then the chain. Dense but every clause carries actionable meaning; slight compactness in the chain notation costs a little readability.

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 mutation with no output schema, the description covers auth requirement, prerequisite (claimed session), error semantics, and the surrounding workflow — everything an agent needs to invoke it 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 documents both parameters (needId, conversationId, including that conversationId comes from contact_need). The description adds no per-parameter detail, which is the correct baseline 3 at full 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?

States a specific verb (confirm completion) targeting the caller's own claimed session, and distinguishes from cancel_need/reopen_need by describing the mutual two-party completion mechanism (authorDone/claimerDone).

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

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

Explicit when-to-use (only one's own claimed session, confirm facts first), explicit error handling guidance (403 non-participant, 409 no claim/already done/need closed — do not retry), and an explicit combination chain get_conversation_needs→confirm→complete_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?

Annotations already declare write (readOnlyHint=false), idempotent, and non-destructive; the description adds auth requirement, the fact that a timestamp is written, and concrete validation rules (FOUNDER needs product and bio, intro optional). It does not elaborate on the response or any side effects beyond the timestamp, so it stops short of full coverage.

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

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

Dense but front-loaded: the login requirement and action come first, then validation, then error handling, then the chain. Bracketed markers impose structure without padding, though the terse clause stacking slightly reduces readability.

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 parameters, no output schema, and annotations covering the safety profile, the description supplies the remaining essentials: precondition, validation gates, error behavior, and sequencing with get_onboarding_status. Nothing critical for correct invocation appears to be missing.

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

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

The tool takes zero parameters, so the schema has nothing to explain and the baseline is 4. The description instead spends its words on preconditions and validation state, which is the right use of space for a parameterless action.

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: after confirmation it marks onboarding complete and writes a timestamp. It also names the sibling get_onboarding_status and clarifies this tool's distinct role in the flow, so an agent can separate it from status-reading 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?

Gives an explicit prerequisite (login required) and an ordered chain: get_onboarding_status → fill gaps → confirm → complete_onboarding. It also gives a when-not rule ('don't blindly retry on incomplete errors; fix first'), which is exactly the routing guidance an agent needs.

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

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

Annotations establish a non-read-only, non-destructive, non-idempotent mutation. The description adds substantial context beyond them: login + organizer role required, draft-only and freeze-after-publish behavior, default preview mode, the consent/previewHash confirmation gate, and the safety-critical constraint that CDKey inventory must be configured by the user in the App and not handed to the model.

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 front-loaded: the login/role bracket and the DRAFT-only constraint lead, followed by the workflow. It uses compact separators and every clause carries information, though the single-run-on paragraph takes effort to parse.

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

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

For a complex, nested, mutation tool with no output schema, the description covers prerequisites, scope, the two-phase preview/save protocol, and the CDKey handling caveat. It stops short of describing what a preview returns or how errors surface, but the essentials for correct invocation are 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?

With 0% schema description coverage the description must compensate. It explains preview defaults to preview mode, consent must be true, previewHash is required for saving, and sketches the config payload (rules/requirements/prizes/quantity/check-in). However, many nested sub-fields (title, imageUrl, redemptionInstructions, cdkeys, item ids) remain undocumented in both schema and description.

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

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

The description states a specific verb+resource with scope: configuring an activity raffle draft ('仅DRAFT配置，开放后冻结'). It clearly distinguishes the draft-config stage from subsequent/live operations, though it does not explicitly name the sibling tools (act_activity_raffle, get_activity_raffle) it differs from.

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 when-to-use context (DRAFT only, frozen after opening) and a precise two-step workflow: default preview, then re-submit the same params with previewHash, consent=true, preview=false to save. No named alternatives, but the invocation flow is unusually concrete.

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 mark this as a non-read-only, non-idempotent, open-world write, and the description adds meaningful context beyond that: login is required, the default is a non-committal preview, committing needs consent=true and a previewHash, and cloud users are manually relayed. The caveat that a conversation does not mean acceptance/joining/confirmed availability is valuable expectation-setting not present in 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 single dense block front-loads the login requirement and flows from the preview default to kind-specific params to the submit contract. Every clause carries information with almost no filler, though the semicolon-packed style is heavy and could be broken into clearer segments.

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 12-parameter, 0%-coverage, write-class tool with no output schema, the description covers the trigger (login), the kind-dependent parameters, the two-step commit contract, the cloud-user path, and the key expectation caveat. Return values are not described, but with no output schema that is not required; the remaining gap is the lack of explicit alternatives to call instead.

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

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

Schema description coverage is 0%, so the description must carry the burden, and it largely does: it explains targetUserId's role for groups (owner/admin/invitable person), that startsAt/endsAt carry a timezone, and the roles of activityId, headcount, spaceName, previewHash, consent and preview. It omits semantics for id/kind internals and message limits, so coverage is strong but not exhaustive.

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?

Combined with the title, the description makes clear this tool initiates contact with a group owner or venue provider through a preview-then-submit flow. It specifies a concrete action (preview then contact) on two resource kinds (群/场地), distinguishing the tool from generic messaging siblings. It never states the purpose in one clean sentence, relying on the title to anchor 'what it does', so it is clear but not maximally sharp.

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 spells out the operating procedure: default preview mode, then resubmit with the same params plus previewHash, consent=true and preview=false. It also routes usage by kind (group uses targetUserId; venue uses activityId/startsAt/endsAt/headcount/spaceName). It does not compare against alternatives like request_activity_cloud_contact_requests or start_conversation, so there are no explicit 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?

Adds substantial behavior beyond annotations: login required, that a real chat/send occurs, no quota cap, and the subtle nuance that claiming is idempotent while the message is re-sent every call. It also maps error codes (400/404/409/429) to a no-retry rule, which is exactly the operational context 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?

Dense but well-structured with bracketed markers (login, chain) that front-load the critical auth constraint and purpose. Every clause carries information, though the density trades some readability.

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 annotations but no output schema, the description covers auth, side effects, idempotency nuance, error handling, and workflow position. Nothing needed to invoke 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 coverage is 100%, so needId and the optional ≤2000-char message are already documented in the schema. The description only restates the length cap and the 'confirm the target first' advice, adding marginal meaning beyond the structured fields, so baseline 3 applies.

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

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

States a specific verb and resource: contact the author of an active need and claim it, plus the concrete side effect of really starting a chat. It is clearly distinguishable from siblings like get_need (read) and complete_need (closing).

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 【组合链】 line gives an explicit call sequence (get_need → contact_need → get_conversation_needs/send_message → complete_need), telling the agent when this step belongs in a workflow. It does not spell out when NOT to contact (e.g. alternatives like start_conversation), so it stops short of full when/when-not 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 it discloses the login and permission requirements, the side effects (creator becomes head, all grants applied, employees auto-join the alliance), and the non-idempotent two-step nature implied by idempotentHint=false, explicitly warning '勿直接重试' (do not retry directly) with a recovery path. This is substantial behavioral context the annotations alone do not convey.

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

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

It is a single dense paragraph with the permission requirement front-loaded and no filler sentences. It is tight, though the run-on phrasing makes it slightly harder to parse the distinct ideas at a glance.

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 mutation tool with nested objects and no output schema, the description covers permissions, side effects, and failure recovery well. However, with 0% schema coverage the eight input parameters (enums, nested formFields, terms) remain unexplained, leaving a real gap an agent would need to fill.

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% across 8 parameters, so the description carries the full burden. It only vaguely references '组织字段/协议' (organization fields/terms) and adds no meaning for name, type, joinPolicy, visibility, description, or formFields structure. It leaves most of the complex nested parameters undocumented.

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

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

The description states a specific verb+resource ('创建' alliance organization) and the resulting state ('我成为负责人并入联盟'), and it explicitly distinguishes the create step from the separate attach step, which separates it from siblings like attach_alliance_organization and create_organization. The core purpose is slightly buried behind the permission preamble but 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?

It specifies prerequisites (login required, alliance manage permission) and the preconditions for invoking (confirm organization fields/terms and the ownership relationship). It also routes the agent on failure to list_my_organization_memberships and explains that creation and attachment are two steps, covering most when/when-not cases without explicit 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?

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?

Beyond the annotations (readOnlyHint=false, idempotentHint=true), it discloses login requirement, order-insensitivity of pairs, the side effect of marking both leads worked=true with revenue-split impact, and execution semantics (processed one by one, failures do not interrupt). These are exactly the behavioral traits an agent needs before calling, and they are consistent with 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?

Front-loads the login prerequisite and the action, then the workflow chain, then reason content rules, then the destructive side-effect warning. Every clause 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?

No output schema exists, yet the description covers prerequisites, batch limit, workflow context, side effects, and per-item failure behavior, which is everything needed to invoke it correctly. Nothing material is left to inference.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: pairs are not left/right ordered, bUserId lets you pass an in-site person not yet in the pool, and reason must be human-language rationale with no scores since it is shown verbatim on four surfaces. That is real semantic guidance beyond the field docs.

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 (create matches / 建撮合) plus scope (after user confirmation, max 20 pairs). It clearly distinguishes itself from the sibling scan_broker_matches by describing itself as the confirmation step that produces the match. An agent can tell it apart from update_broker_match and create_broker_lead 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 an explicit pipeline: scan_broker_matches → user confirmation → this tool → get_broker_intro_scripts (external) or introduce_broker_match (in-site group). It also states a when-not: do not use for test runs because leads get marked worked=true and revenue split is affected.

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

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

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

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

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

The description is compact and every sentence carries operational value: creation semantics, timeout handling, and a pre-creation check plus downstream id usage. It is front-loaded with the core purpose and contains no filler or redundant restatements of the schema.

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

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

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

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

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

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

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

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

The description opens with a specific verb and resource: '创建一个持久的独行录合作目标' (create a persistent collaboration goal) and clarifies that '用户成为发起人' (the user becomes the initiator). This clearly distinguishes the tool from siblings like create_collaboration_task by naming a distinct resource and describing its key semantic.

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

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

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

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

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

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

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

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

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

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

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

For a side-effecting, non-idempotent creation tool with no output schema, the description covers the most important operational concerns: authorization, notification, timeout handling, and verification via get_collaboration_goal. It does not explicitly describe the success return value, but its verification guidance effectively compensates for that gap.

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

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

Schema description coverage is only 20%, so the description must compensate. It does clarify assigneeId semantics (omitted means self, must be a goal collaborator if specified), but it does not explain title, detail, or goalId meaning beyond obvious inference, and dueAt semantics are left to the schema. That is partial compensation for a low-coverage schema.

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

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

The description states a specific action and resource: creating a task within a collaboration goal, and it explicitly covers assignment behavior when assigneeId is provided. This distinguishes it from siblings like create_collaboration_goal and update_collaboration_task, since it is clearly about task creation/assignment rather than goal creation or task modification.

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

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

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

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

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

Annotations cover the safety profile (readOnly=false, idempotent=false, openWorld=true, destructive=false), and the description adds materially beyond that: partial-failure semantics with no rollback, results reported as created/failed, one notification per assignee, login requirement, and the assignee-defaults-to-self rule. This is exactly the operational context 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?

Dense, front-loaded with the 【需要登录】 prerequisite, then the scope limit, then mode semantics, then failure/notification behavior. Every clause carries operational information; nothing is 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?

With no output schema, the description still covers the return contract (created/failed reporting), partial-failure behavior, prerequisites, and the sibling tool to call first, which is more than adequate for a 3-param batch tool. Minor gap: it does not say whether the created/failed result is per-item indexed, though this is not critical 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 67%. The description adds real meaning for 'preview' (dry-run that returns a would-create/would-fail list for user confirmation) and clarifies the ≤10 bound and the assignee default, none of which is fully spelled out in the schema. goalId semantics remain unexplained, but it is self-evident from 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 specific verb+resource+scope: '同目标批量派任务≤10' (batch-dispatch tasks under a single goal, ≤10). The '批量' + cap framing distinguishes it from the single-task sibling create_collaboration_task without naming it. Naming the sibling explicitly would have earned a 5.

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

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

It prescribes the preview workflow explicitly (preview=true to check permissions/members and confirm, false to create one-by-one), states the login prerequisite, and routes non-members to an alternative tool (invite_collaboration_member) before assignment. It also gives a merge-prompt rule when one person gets >3 tasks, so an agent knows the when, the when-not, and the fallback.

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 safety (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description adds non-obvious behavior: login requirement, immediate public visibility (立即公开), asynchronous processing triggered (触发异步处理), and slug_taken recovery. These are exactly the traits an agent cannot infer from the schema.

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

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

Two dense sentences with bracketed tags front-loading the login requirement, then the chain. No wasted words; every clause carries a distinct fact (auth, uniqueness, visibility, async, error recovery, workflow).

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 mutation with no output schema, the description covers auth, uniqueness, side effects, error handling, and workflow position, which is nearly everything needed. It could note what the async processing produces, but annotations and schema carry the rest.

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 9 parameters, giving a baseline of 3. The description adds real value beyond that by explaining the slug_taken conflict path (换slug), which is a behavioral constraint on the required slug 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?

States a specific verb and resource (创建/更新本人公司) plus the key scope constraint 一人一家 (one company per person). An agent can distinguish it from update_my_company and create_organization because the uniqueness rule and the confirm-then-create framing are explicit.

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

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

Provides prerequisites (需要登录) and an explicit ordered chain get_my_profile→确认资料→create_company→complete_onboarding, which tells the agent exactly where this fits. It does not explicitly contrast with the update_my_company sibling, so it stops short of 5.

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

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

Annotations only declare the basic safety profile (readOnlyHint false, openWorldHint true, idempotentHint false, destructiveHint false). The description adds substantially more: login requirement, that the counterparty is notified but notification does not imply acceptance, that execution re-validates two-way visibility/blocking/status/quota, and the prohibition on auto-filling the login phone/profile.

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

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

It is a single dense paragraph that is front-loaded with the login gate and the preview/execute distinction, and every clause carries operational information. Slightly terse and jargon-heavy, but no filler sentences.

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

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

Given 9 params, no output schema, and a two-phase consent flow, the description covers prerequisites, parameter relationships, side effects (counterparty notification), and revalidation. It never describes the response/preview payload contents, but with no output schema that omission is minor.

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 schema coverage at only 22%, the description carries the load and does so well: it explains activityId/organizationId mutual exclusivity and the public default, the previewHash execute handshake, consent=true, preview=false, note being self-provided, and contact/shareContactConsent rules. This meaningfully compensates for the sparse schema documentation.

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

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

The description conveys a specific verb+resource flow: sending a participant communication request via a preview-then-commit sequence, scoped by activityId/organizationId (at most one, neither = public). It does not literally name sibling tools, but the consent/preview mechanics clearly separate it from the read/scoped siblings like get_connection_request or respond_connection_request.

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

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

It gives concrete usage procedure: default is preview; execution requires the same params plus previewHash, consent=true, preview=false, only after the person explicitly consents to target and reason. Prerequisites (login, explicit consent) are stated, though no explicit alternative-tool routing is offered.

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?

Annotations already declare readOnly=false, openWorld=true, idempotent=false, and destructive=false. The description adds substantial non-obvious behavior: login requirement, notification on assignment to others, authorization over person/content, server-side relationship verification, a 50-per-Beijing-day rate limit, and the absence of a persistent request dedup key with a warning not to auto-resend.

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 front-loads the login requirement and core direct-assignment behavior before operational constraints. Every clause addresses a real usage concern, though the sentence structure is compact to the point of being terse for a complex mutation.

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, open-world mutation with no output schema, the description supplies authentication, authorization, rate limits, side effects, verification alternatives, and retry caution. This is complete enough for an agent to invoke and handle 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%, so the description must compensate. It clarifies assigneeId (omitted means self; assigning others sends notification) and organizationId (organization label with server-side relationship verification), but title and detail remain semantically undocumented beyond their schema constraints, and dueAt is already described 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 and resource: directly create/assign a task without attaching it to a goal, evidenced by '不挂目标直接派任务' and the goalId=null receipt. This distinguishes it from the goal-attached sibling create_collaboration_task, so an agent can identify the correct tool 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 gives prerequisites (login required), default behavior (omitted assigneeId means self), side effects (assigning others notifies them), authorization needs, and a daily cap. It also names alternatives for finding people (list_collaboration_task_assignees) and verifying results (list_collaboration_tasks), plus retry guidance after timeout/unknown outcomes.

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 adds the login/auth requirement (【需要登录】), the public visibility of the post, and explicitly warns there is no deduplication so repeated calls create duplicate posts — context that aligns with and enriches idempotentHint=false. It does not describe the response shape, but the behavioral additions are meaningful and non-contradictory.

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 content is front-loaded (auth requirement first) and every clause carries useful guidance. However, it is packed into a single dense semicolon-chained sentence with bracketed markers, which makes it harder to parse than a cleanly segmented version would be.

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 create tool with no output schema, the description covers auth, visibility, duplicate-post behavior, the default type, the sibling alternative, and the follow-up workflow. It omits any note on what is returned, but that is a minor gap given the otherwise thorough coverage.

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 75% schema coverage the baseline is 3, but the description adds semantics beyond the schema: it reinforces the COLLAB default while warning against GIG specifically, and instructs the agent to confirm the title/detail text first. These are marginal but genuine additions on top of an already well-described 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 conveys that this posts a public recruitment need on a collaboration goal and explicitly differentiates itself from siblings, telling the agent that other-object needs use create_need and that GIG is the wrong type. The core 'what it does' statement is somewhat implicit ('目标合作人均可公开招募'), leaning on the name/title, but an agent can still identify the resource and scope without opening a 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 gives explicit when-to-use and when-not-to-use guidance: use this for goal recruiting, use create_need for other object needs, don't misuse the GIG type. It also prescribes the surrounding workflow (check claims via get_collaboration_goal(include=recruits), then invite_collaboration_member), 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?

Adds substantial context beyond annotations: it discloses the management-permission requirement, the two-step preview→confirm workflow (same params + previewHash, preview=false, re-confirm on change), and re-verification of identity, phone and audience at fill time. Annotations only cover the safety profile, so this is real added behavioral information.

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

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

Front-loaded with the permission requirement in brackets, then scope, then the workflow. Dense but every clause carries meaning; slight cost from packing multiple rules into run-on clauses, but 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 mutating, open-world tool with no output schema, the description covers auth, targeting rules, and the preview/confirm lifecycle well. Return values are not described, but no output schema exists so that is not required; remaining gap is minor.

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 and mostly does: it explains preview's default, the previewHash confirmation mechanic, and that targetUserId is mandatory for private activities. activityRef itself is only implied as the subject activity, so one of four params is left slightly under-explained.

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: prepare general/targeted filling links, and immediately delimits scope with '不代发、不扩大受众' (does not send, does not expand audience). This lets an agent separate it from send_guest_invite_now and similar send tools, though it does not name the closest siblings (create_guest_invite_link / create_guest_open_link) explicitly.

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

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

Gives concrete when-to-use conditions: private activities require targetUserId plus existing audience eligibility, targeted links are handed only to the person, and the default is preview with confirmation via previewHash. No explicit exclusion of a named alternative, but the '不代发' clause implies when another tool should be used 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?

Annotations already flag non-idempotent, non-readonly, open-world behavior, and the description adds materially beyond them: the link is a secret key valid 14 days that must only go to the guest, each call mints a new card while old cards stay valid, and only public sessions qualify. This is exactly the operational context an agent needs before invoking a link-generating mutation.

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

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

Front-loaded purpose, then a bracketed composition chain, then a bracketed pitfalls section. Every line earns its place; no filler and the critical warnings are surfaced rather than buried.

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 2-param mutation with no output schema, the description covers auth requirements, the upstream/downstream tool chain, link secrecy, validity window, re-mint semantics, and a session-type gate. An agent can call this correctly without consulting anything else.

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 already documented there (guestId sourced from list_activity_guests, activityRef a slug or id). The description reinforces the guestId provenance but adds no syntax or format detail 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?

States a precise verb+resource: mint a self-service card link for a specific guest, and specifies what the guest can do with it (confirm attendance, edit title/topic, upload avatar and PPT without login). The 【需要登录·主办方】 prefix scopes the actor, distinguishing it from the many other guest-related 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 lays out the composition chain (list_activity_guests / add_activity_guest → this tool → send_message, with start_conversation for on-site userIds) and states the hard precondition that only public sessions can mint cards. Nothing about when to use or not use it is 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 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?

Annotations already declare a non-read-only, non-idempotent, open-world write. The description adds genuinely new behavioral context: it triggers async matching/push, requires login, requires images to be mirrored first, and constrains context objects to the caller's own. Useful beyond the annotations, though it does not describe reversibility (delete_need/cancel_need exist nearby but aren't referenced).

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?

Densely packed into bracketed clauses with the critical login requirement front-loaded. Every clause carries information, though the density and bracket notation make it slightly harder to scan than a plain-sentence version.

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 annotations and full schema coverage but no output schema, the description covers auth, side effects, param constraints, and the follow-up/alternative tools. Complete enough to call correctly; it just omits return-shape expectations and lifecycle (cancel/complete) 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 100%, so the baseline is 3, but the description adds ownership semantics ('contextType/contextId 成对且须本人对象') and reinforces the 3–120 char title and image-mirroring requirement. This goes modestly beyond what the schema fields state.

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 (发布真实公开需求 / publish a real public need) and explicitly routes modification to the sibling update_need. An agent can distinguish create from update_need without opening either schema, and the schema further disambiguates create_goal_recruit_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?

Gives explicit preconditions (login required, confirm title/detail first) and a follow-up chain (create→get_need_recommendations→get_creator/contact_need) plus the alternative for edits (update_need). Clear context, though it does not spell out when NOT to use this tool or contrast against create_goal_recruit_need.

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