独行录 / opcmenu

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

Annotations supply only destructiveHint=false, so the description carries the burden, and it does: it discloses that MEET creates a real conversation and sends a message under the user's identity, that the default opener is previewed and requires authorization, that signup success is never proven (always signupVerificationRequired=true), and that no server-side request dedupe key exists, with short-circuiting only for already-completed acceptances. These are exactly the side-effect and idempotency facts an agent cannot infer from 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?

It is front-loaded with the core action before the mode-specific behaviour and caveats, and nearly every sentence adds non-redundant operational fact. It is, however, a dense unbroken block with several warning clauses packed together, which costs some 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 two-parameter mutation with no output schema and only a destructiveHint annotation, the description covers prerequisites (login), per-mode side effects, return-signal semantics (signupVerificationRequired, hasSignupRecordHint, openSignupSlug), the verification path, and the retry/idempotency policy. Nothing material needed to call it safely is missing.

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

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

Schema coverage is 0%, so the description must compensate; it does so fully for 'opener' (omitting it triggers the platform's pre-written opener, shown to the user first for authorization; 400-char cap left to the schema). 'arrangementId' gets only indirect meaning, implying it comes from get_my_dispatch suggestions with no format or failure behaviour for an invalid ID.

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

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

The description states a specific verb and resource ('接受 get_my_dispatch 的建议') and then splits the behaviour into two named modes, MEET (builds a real conversation and sends an opener as the user) and ATTEND (attempts signup). This makes it clearly distinct from the sibling decline_dispatch_arrangement and from get_my_dispatch itself, which is named as the prerequisite.

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

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

It explicitly names the upstream tool (get_my_dispatch), the follow-up verification tools (get_signup_activity along with the next hint, list_my_signups), and the fallback when an external form is involved (submit_signup). It also gives an explicit when-not-to-act rule: after an unclear result or timeout, query the current value instead of re-sending.

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 and destructiveHint=false, and the description goes beyond them by naming the real side effect (stops subsequent SMS for that round), the semantic scope (not a signup, attendance, cancellation, or check-in), and a timing nuance (前三天确认不取消前一天提醒). However, that last clause is phrased elliptically and the description never says what the call returns or what happens on an already-acknowledged or expired reminder, so it stops short of full behavioral disclosure despite being far above the annotation baseline.

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 trigger condition, then the effect, then the boundary rules, so the most important guidance comes first. It is dense but nearly every clause carries a distinct rule; the leading fragment '登录;' and the compressed final clause make it slightly harder to parse than it needs to 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 one-parameter, non-destructive, idempotent acknowledgment tool with no output schema, the description covers precondition (login), trigger, side effect, semantic boundaries, disambiguation, and batching prohibition. An agent has everything needed to decide and call correctly.

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

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

Schema coverage is 100% and the single parameter is already documented, so the baseline is 3. The description still adds genuine guidance: reminderId 从聊天中的活动提醒取得, and if multiple reminders or ambiguous reference exist, ask first rather than guess — that is disambiguation policy the schema does not carry.

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 (确认/acknowledge) on a specific resource (所指的那一轮提醒) and the concrete effect (停止该轮的后续短信). It also explicitly fences off adjacent actions (报名、同意出席、取消报名、签到), so an agent can tell it apart from respond_activity_invitation or check_in_my_activity 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?

Gives an explicit trigger (用户本人明确说「知道了」「收到提醒了」), explicit exclusions (不能从已读、询问或系统通知推断确认), explicit prohibitions (不能替别人确认、绝不批量确认), and a disambiguation rule (多场或指代不清先询问). This is close to a complete when/when-not specification.

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

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

With no annotations, the description carries the full behavioral burden and discloses important effects: withdraw returns the raffle to draft while preserving prizes/inventory/check-in only under stated conditions, complete publishes the seed and permanently ends the raffle, and preview uses previewHash plus consent. It still omits validation/error behavior and any rate-limit or failure-mode details.

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

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

The description is compact and front-loads the action semantics, then preview/retry rules, then action-specific requirements. The semicolon-separated fragments make it dense and somewhat hard to parse, but there is little wasted text.

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

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

For a 12-parameter lifecycle tool with no annotations and no output schema, it covers most action semantics and the preview workflow. However, it omits the action-to-parameter mapping for cases such as review deciding approve/reject, and it does not explain reason or expected return/error behavior, leaving meaningful gaps for an agent to infer.

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?

At 0% schema description coverage, the description explains many key parameters and actions: prizeId for draw, drawId for review, previewHash/consent/preview for the preview flow, requestId for retries, evidenceReviewedByUser for review, and claimCode for claim. It leaves decision (approve/reject), reason, activityRef, and action-specific required parameter mappings unexplained.

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

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

The description names the raffle lifecycle actions (open/withdraw/lock/draw/review/claim/complete) and the organizer/login context, so the tool's purpose is clear. It does not explicitly distinguish this lifecycle tool from siblings such as configure_activity_raffle and get_activity_raffle, though the action list implies the difference.

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

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

It provides concrete usage rules: organizer/login, preview first with the same parameters plus previewHash, consent=true and preview=false, preserve requestId on retries, review only after user evidence, and claimCode supplied by the user. It also gives a specific precondition for withdraw (no participants and unlocked), but it does not explicitly name alternatives for configuration or read-only workflows.

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 set destructiveHint=false, while the description adds the login/organizer requirement, confirmed=false default hiding from the public page, avatar self-service, a per-event limit of 30, and the fact that this tool does not notify. These are exactly the mutation and side-effect details 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 front-loaded: login/organizer and 'only add' come first, followed by conditional visibility, capacity, and notification caveat. Every clause carries operational meaning; nothing is padded.

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 6-param mutation with a rich input schema and only destructiveHint=false, the description supplies auth, visibility, capacity, duplicate handling, and notification boundaries. No output schema exists, but the description gives enough to call 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?

All six parameters already have schema descriptions at 100% coverage, including the confirmed and userId semantics that the description largely repeats. The description adds a per-event limit and avatar note but no new parameter-level syntax beyond the schema, so baseline 3 is appropriate.

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

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

The description opens with '只新增嘉宾' (only adds a guest) and scopes it to logged-in organizers, then separates it from status changes and invite-link sending. The resource and scope are clear from the guest/activity context, and it explicitly says not to use it for existing guest status changes.

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 organizer/login precondition, says not to use it for existing guestId duplication or status changes, and routes notification to create_guest_invite_link. It lacks an explicit instruction to check list_activity_guests first or how it relates to add_guest_candidates.

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

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

Annotations only provide destructiveHint=false, so the description carries the behavioral load and does so well: it discloses the auth/role requirement, the 30MB fetch cap, that the URL is copied into private storage, that images are auto-moderated, that SLIDES/FILE broadcasts to registrants, and the default visibility per kind. 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?

It is dense and front-loaded: auth/role, then storage/limit, then side effects, then follow-up tools. Every clause carries information, though the telegraphic style and the unexplained '/pro' reference cost 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 5-parameter write tool with no output schema and minimal annotations, the description covers access control, input limits, storage semantics, moderation, notification side effects, defaults, and verification/editing alternatives. An agent can call this correctly without further 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 a baseline of 3 applies; the description adds real value beyond the schema by stating the default visibility resolution (PHOTO defaults to PUBLIC, all other kinds to REGISTERED) and by tying the name field to what registrants will see. It does not clarify enum trade-offs for kind beyond the broadcast note.

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

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

The description states a specific verb and resource: fetch a public direct link and store it as private activity material. It distinguishes the by-link path from large-file handling ('大文件用/pro') and names the follow-up tools list_activity_materials and update_activity_material. It does not explicitly distinguish itself from prepare_activity_material_upload / upload_image_from_url, so it falls short of a 5.

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

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

Prerequisites are explicit ('需要登录·主办方'), the size ceiling (≤30MB) and the large-file escape hatch (/pro) are stated, and the description tells the agent to confirm the filename and visibility before publishing SLIDES/FILE because that triggers a broadcast to registrants. It also routes post-hoc verification and edits to the correct 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?

Beyond the minimal destructiveHint=false annotation, the description discloses important behavior: login/organizer requirement, SPEAKER-only scope, no reordering, vector+model cost and ten-plus-second latency, a pause for human review, and an exit path when no new people are found. It still does not clarify exactly what is persisted or how candidates are returned, so it is strong but not exhaustive.

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

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

The description is dense and front-loads the access and role constraints, then the workflow, then cost and post-completion behavior. It uses compact arrow notation and jargon such as 'exits' that may slow comprehension, but nearly every phrase carries operational meaning.

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, model-backed candidate generation tool with no output schema, the description covers access, role limits, cost/latency, workflow sequencing, review pause, and the no-new-candidates case. It is still somewhat terse about what the tool returns and what 'exits' concretely means, leaving minor gaps for an agent.

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

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

Schema coverage is 100%, so the schema already documents both parameters, including the role enum and the server-side rejection of ATTENDEE. The description repeats the SPEAKER-only constraint but adds no new syntax or format details for activityRef or role beyond what the schema provides, which matches the baseline of 3.

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

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

The description states a specific action: append guest candidates for SPEAKER only and explicitly says it does not reorder. This distinguishes it from reordering or automatic ATTENDEE matching, but the core effect of generating a new candidate batch is only implied through the title and the workflow reference to set_guest_invite_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?

It gives an explicit workflow: set_guest_invite_plan changes the brief, then this tool runs, then get_activity_invites is used for review. It also states hard restrictions (SPEAKER only; ATTENDEE cannot be supplemented), warns against calling twice in one conversation, and says to pause and confirm before calling set_guest_invite_plan_status(start).

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 lone destructiveHint=false annotation, the description discloses per-type default visibility (phone=private, IM tools=friends, rest=public), that public contact methods require explicit visibility plus confirmation, and that public links become visible to get_creator. These are non-obvious side effects and privacy consequences that 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?

It is short and front-loads the append semantics and defaults, but the arrow notation and semicolon-chained clauses make it telegraphic and slightly harder to parse than plain 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?

For a 4-parameter mutation with no output schema and only a destructiveHint annotation, the description covers login requirement, defaults, confirmation for sensitive visibility, and a verification step. It is nearly complete, with only minor gaps around duplicate-link handling and error behavior.

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 url, type, label, and visibility, including the per-type defaults and enum. The description restates the default-visibility rule, adding reinforcement but little information the schema did not already supply, so the baseline 3 applies.

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

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

The description makes it clear that the operation is appending one of your own links (bot), and that it does not overwrite existing links. That distinguishes it by purpose from remove_profile_link or set_link_visibility, though this description does not name the sibling tools 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?

It gives an explicit workflow sequence (get_my_profile → add → get_my_card) and a login prerequisite, which tells the agent when in a flow to call it. It does not say when NOT to use it or point to set_link_visibility/remove_profile_link as alternatives, so a 4 rather than 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?

Beyond the single destructiveHint=false annotation, it discloses meaningful behavior: the analysis does not notify the counterparty, does not modify the plan, and never forwards private plan content or personal data to search. These are exactly the side-effect and data-egress facts an agent needs and are not derivable from the annotation.

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

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

Four tight sentences with zero filler, and the most important constraint (only user-visible plans) is front-loaded. The density is high but each clause carries an operational rule.

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

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

For an 11-parameter, nested-object tool with no output schema and only a destructiveHint annotation, the description covers the safety/data-sharing posture but not how to actually compose a call: the roles of message/context/history/selection, the meaning of planId and shareAccessId, or when expectedRevision/expectedDocumentHash must be supplied. An agent could not reliably build a valid request from this.

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% across 11 parameters, so the description carries the full burden, yet it explains only useMyProfile, research.enabled, and industryTopic (adding the important 'de-identified public topic' constraint). The other parameters (planId, message, context, history, requestId, selection, shareAccessId, expectedRevision, expectedDocumentHash) get no semantics at all, including the nested objects and the optimistic-concurrency fields.

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

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

The title '私有合作阅读顾问' and the phrase '分析' imply an advisory/analysis function over a cooperation plan, but the description never states the core action explicitly (e.g., 'given a message, advise on a cooperation plan'). What is present is a set of scope rules ('只用当前用户可见方案') rather than a verb+resource statement, and it does not distinguish this tool from the close sibling get_cooperation_analysis.

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?

Strong conditional guidance for the risky optional parameters: 'useMyProfile需用户授权' states the precondition for using profile data, and 'research必须用户明确要求' states the trigger for research mode. It stops short of telling the agent when to reach for this tool over get_cooperation_analysis or get_cooperation_plan, so it is 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?

With no annotations, the description carries the full burden and does it well: it discloses the auth requirement, the role restriction, a mandatory user-confirmation step, the side effects (sharing content, management/auto-entry capability, possible forced alliance switch), the downstream notification to the alliance manager, and the meaning of the APPLIED status (not yet joined).

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

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

One dense paragraph that front-loads the login/role gate, then the workflow, then the status semantics. Every clause adds information, though the compression makes some phrases (e.g. '管理/自动进驻能力') hard to parse without 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 annotations and no output schema, the description covers permissions, required workflow, irreversible-ish side effects, notifications, and result status. Missing only parameter-level detail and how it relates to the other alliance-application siblings.

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%, and the grants enum is already documented inline in the schema. The description adds the conceptually important point that grants must be a complete list including mandatory items, but it says nothing about organizationId, allianceId, or note beyond an implicit 'read the org and target alliance first'.

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

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

The description states a concrete verb+resource ('apply organization to alliance', submit application on behalf of an organization) and the title reinforces it. It does not explicitly distinguish from the sibling submit_alliance_application, so an agent must infer the org-vs-personal scope difference.

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 preconditions and a workflow: login required, must be actual owner/admin, read org relations and target alliance first, present the full grant list to the user, and submit only after confirmation. It stops short of naming alternative tools (e.g. invite_organization_to_alliance vs submit_alliance_application) for contrast.

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 carries real behavior beyond the annotations: login is required, the submission is genuinely persisted and visible to admins, a 43-character invitationToken causes immediate admission, and duplicate calls return the existing record rather than creating new progress. That materially extends idempotentHint=true, though it leaves acceptContactSharing and the shape of the returned record (beyond joined/pendingReview) unexplained.

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 nearly every clause carries operational information; nothing is padding. It is a run-on semicolon chain rather than a structured list, and it opens with the low-value 'login' note instead of front-loading the agreement pre-check 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 six-parameter mutation with nested answers, no output schema and no enum coverage, the description supplies the prerequisite tool call, the conditional parameter rule, the invitation shortcut, the idempotency behavior, and the meaning of the joined/pendingReview response flags. An agent can execute this correctly without further lookup.

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

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

With only 17% schema description coverage, the description does the heavy lifting: it explains acceptTerms and termsVersionId as a pair gated on the presence of an agreement, describes invitationToken's pre-approval semantics and its 43-character format, and constrains answers keys to those supplied by formFields. acceptContactSharing is never mentioned, and 'currentTerms.id' does not match the actual parameter name termsVersionId, which costs a point.

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 action+resource: a real, admin-visible membership application with the agreement-confirmation precondition. It implicitly distinguishes itself from invite-response flows (respond_organization_invite) and from the follow-on submit_signup, but it never states plainly 'apply to join an organization' — the purpose must be inferred from the title and the surrounding clauses.

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 sequencing: call get_organization(includeTermsBody=true) first, show agreement title/full text and each question's answer, obtain explicit user consent, then apply. It also gives the branching rule (with agreement: currentTerms.id + acceptTerms=true; without: omit both) and the do-not-repeat rule when the result is an existing member or PENDING record.

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

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

With no annotations at all, the description carries the full burden and mostly covers it: login requirement, the blast radius (delisting stops public display/search, but data is retained and owner-visible), reversibility via re-publish on edit, an ownership/version-change rejection rule, and a preview/confirm safety flow. Only the preview response shape (e.g., where previewHash comes from) is left implicit.

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 gate and the core effect, then the workflow, then the alternative — the ordering is exactly right. It is dense and semicolon-chained, which slightly hurts scannability, but almost every clause is load-bearing.

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, no-annotation, no-output-schema, state-mutating tool, the description supplies enough to call it correctly and safely: ownership scoping, preview-first pattern, consent gating, and the delete-vs-archive boundary. The remaining gaps (what preview returns, hash validity window, recovery path) are 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 only 25%, but the description explains the semantics of the three otherwise-undocumented parameters: '默认预览' (preview default), 'previewHash' (returned by preview, must be passed back), and 'consent=true' for execution with 'preview=false'. This substantially compensates for the low coverage, though it doesn't spell out format/expiry constraints.

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

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

The description names a specific verb + resource ('仅下架指定本人公司主页') and precisely scopes the effect: stop public listing/search, keep the data, owner still sees it. It also explicitly distinguishes itself from the sibling delete_my_company ('彻底删除用 delete_my_company'), so an agent can pick the right tool 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?

It states the prerequisite (【需要登录】), the required precondition (only your own company), the two-step flow ('先 get_my_company'), the default behavior ('默认预览'), and the exact confirmation sequence ('同参+previewHash、consent=true、preview=false'). The alternative (permanent deletion) is named with its condition.

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 supply destructiveHint=false, so the description carries the real load and does: it discloses a permission grant side effect ('目标合作人随即获得活动管理权'), a login requirement, and an ownership restriction. It stops short of covering idempotency (what happens if the activity is already attached) or failure modes, which keeps it off a 5.

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

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

Four tight, front-loaded clauses with no filler; the action, side effect, and constraints all land in one dense sentence. The semicolon-chained style is efficient but slightly harder to scan than separated 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?

For a two-parameter mutation with no output schema and minimal annotations, the description covers auth, ownership, source data, side effects, and verification. Missing only edge-case behavior such as duplicate attachment or permission-denied handling.

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

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

Schema coverage is 50% – activityRef is already documented in the schema, and the description's mention of 'list_my_activities或attachable' reinforces where that ref comes from but adds no format detail. goalId remains undocumented in both places, so the description only partially compensates.

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: attaching one's own activity to a collaboration goal ('把本人活动挂到合作目标'), and immediately names the consequence (collaborators gain management rights). The ownership qualifier ('本人活动') separates it cleanly from detach_activity_from_goal and from any admin-style attachment 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?

Gives prerequisites ('登录'), where to get the activity from ('活动取list_my_activities或attachable'), a post-condition check ('挂后get_collaboration_goal核对'), and an explicit exclusion ('不能代挂他人活动'). An agent has everything needed to decide whether to call this or its sibling.

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

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

With no annotations, the description carries the full burden and does well: it discloses auth requirements, side effects (old alliance relationship removed, linked access cascade, notification to the old alliance) and an implicit side effect (employees auto-join). It does not say whether the merge is reversible or how conflicting memberships are handled, and the '全部7项授权' (all 7 grants) reference is unexplained without consulting sibling grant tools.

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 dense but efficient two-sentence block, front-loaded with the login/permission gate, then side effects, then the pre-check step. The single cryptic aside about '7 grants' slightly dilutes the otherwise tight 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 two-parameter mutation with no annotations and no output schema, the description covers prerequisites, side effects, verification steps and failure handling, which is nearly everything an agent needs before calling it. Missing only success/reversibility information and the meaning of the referenced grants.

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

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

Schema description coverage is 0%, so the description must compensate. It only loosely maps the two parameters to 'target alliance' and 'organization' ('确认目标联盟、组织'), without specifying ID formats or what '确认' means concretely — you are told to verify them but not what a valid value looks like.

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 action ('并入自有' – attach the organization as alliance-owned) and resource (alliance + organization), and it embeds a distinction between becoming alliance-owned versus an existing share/affiliation ('若换联盟会移除旧关系'). However, it never names a sibling (e.g. create_alliance_organization, apply_organization_to_alliance, set_alliance_organization_share) to differentiate itself, so the distinction must be inferred from the title.

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?

Preconditions are explicit ('需要登录', alliance manage role, org owner) and a required pre-check workflow is given ('先查双方详情'), plus fallback guidance on failure ('失败查实际关系'). It does not state when to use an alternative tool instead, so it stops just short of full routing guidance.

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

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

Annotations supply only idempotentHint=true, so the description carries the behavioral burden and does so thoroughly: it discloses the cascading side effect (hiding all historical and pinned messages in this session plus a broadcast), the blast radius (no account ban, other sessions unaffected), and the repeat-call semantics (重复保持禁言), which is consistent with the idempotent annotation. It even documents what the returned counts mean (hidden = 实际总数, notified = 广播项数, possibly capped at 200, not delivery count) — context that no structured field provides.

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

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

The prerequisites and scope limits are front-loaded before the side effects and the return-field caveats, and essentially every clause carries information an agent needs (identity check, side effects, scope, batch prohibition, retry policy, count semantics). It is a dense run-on block with semicolon-chained clauses, which costs some readability but wastes little content.

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

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

For a destructive moderation tool with no output schema and minimal annotations, the description covers everything material: authorization, pre-call verification, exact side effects and their scope, non-effects, batching limits, idempotent behavior on repeat, and the meaning of the returned counters. Nothing an agent needs in order to call it safely is missing.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters, including the instruction to verify the target's nickname/id and to obtain liveId from get_activity or get_organizer_live. The description's 确认活动/场次/范围 and identity-check phrasing largely restates that, adding only mild operational emphasis rather than new parameter meaning, so the baseline 3 applies.

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

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

The description names a specific verb and resource in the very first clause (本场禁言 + 隐藏此人本场全部历史发言和置顶), and explicitly bounds it against adjacent actions: 不封号 (not an account ban, distinguishing it from block_user) and 不影响其他场 (session-scoped only, unlike account-level tools). An agent can tell it apart from unban_live_user and block_user 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 required caller identity (登录/本场主办方), the pre-call verification step (先主持台核对targetUserId与本人，确认活动/场次/范围), and an explicit prohibition (勿擅自批量). It also gives the failure-handling rule: 未知结果先核验，禁止自动重试, which is exactly the kind of when-to-use/when-not guidance an agent needs for a moderation action.

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' clause earns no credit. The description does add real value by disclosing the unilateral side effect that the annotations do not convey: mutual DM blocking and automatic removal of mutual follows. However it omits reversibility (unblock_user) and what happens to existing conversations, and the hidden follow-removal is in mild tension with destructiveHint=false even if not a direct 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?

Very dense and front-loaded: purpose, effects, when-to-use, then idempotency. The semicolon-chained telegraphic style and the bare '登录;' prefix make it slightly harder to parse than it needs to be, and the idempotency clause duplicates the annotation.

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

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

For a single-parameter mutation tool with no output schema and partial annotation coverage, the description covers purpose, side effects, use case, and repeat-call behavior — enough to call it correctly. Missing only the reversal path and the auth/permission requirement implied by '登录'.

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

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

Only one parameter, and the schema already documents userId at 100% coverage ('要拉黑的用户 id'). The description adds no format, lookup, or self-block/precondition guidance 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?

A specific verb + resource ('拉黑某用户') followed by the concrete effects (mutual DM block, auto-unfollow), which lets an agent understand the operation without opening the schema. It does not name or distinguish itself from nearby siblings such as unblock_user, ban_live_user, or list_my_blocks, so it stops short of a 5.

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

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

'处理骚扰时用' gives an explicit use context (handling harassment) that an agent can match against a user request. There are no exclusions or alternatives, though — nothing says when to prefer report_content or ban_live_user over blocking, and no mention of unblock_user for reversal.

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 carry idempotentHint=true, so the description must carry the rest — and it does: it warns that execution really pushes notifications and is irreversible, that processing is serial per item, how partial failures surface, the write rate limit of 30, and the organization_rate_limited retry path. It also states the required login/OWNER/ADMIN authorization level.

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 dense and front-loads the two constraints that matter most (auth scope, 100-item cap) before the irreversible-write warning and the workflow arrow chain. The semicolon-chained, telegraphic style packs a lot into a short block, though the run-on phrasing costs 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?

With no output schema, the description still tells the agent what to expect back (per-item succeeded/failed, partial failure reasons, specific error codes) and how to recover from throttling. Auth requirements, limits, irreversibility, and the confirm-before-execute protocol are all covered for a destructive bulk mutation.

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 framing preview as a mandatory dry-run gate (default true, must explicitly pass false to commit) and by instructing that reason text be read back verbatim during preview. It adds less about organizationId and the per-decision decision enum, which the schema already covers.

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

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

The description states a specific verb+resource combination (处置入会申请, up to 100 at a time) and anchors it to the upstream step list_organization_applications(pendingOnly=true), so the agent knows it operates on organization membership applications rather than signup submissions. It does not explicitly name the near-sibling bulk_review_signup_submissions to draw the contrast, which keeps it from 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 exact sequence: list pending applications, run preview=true, read the names and reason text to the user for confirmation, then re-call with preview=false. It also states the exclusion case (already-reviewed applications with a different conclusion cannot be overturned and must be reported via organization_application_resolved).

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 supply idempotentHint and destructiveHint=false; the description adds the operative context an agent actually needs — login plus organizer permission requirement, that applicants see the result immediately, that ids from other activities are silently ignored, that reviewNote cannot be emptied because cleared messages are unrecoverable, and the requested/updated/ignoredIds report shape. None of this contradicts the annotations; the note about not clearing notes is a usage restriction, not a claim of destructiveness.

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

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

Permission scope is front-loaded in brackets, then the workflow, then limits, then the return contract — a sensible ordering with zero filler. The arrow/telegraphic style and compressed terms (投递态, 余者) make it dense, which costs a point on readability but not on substance.

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 mutation with no output schema, the description covers the missing pieces: prerequisites, the confirmation gate, the batch cap, the ignored-id behavior, the report fields a caller should surface, and the one destructive-adjacent pitfall (irreversibly clearing notes). Very little an agent needs in order to invoke this safely is left unstated.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters and the baseline would be 3. The description still adds meaning beyond the schema: preview is framed as the mandatory dry-run gate in the confirm workflow, and ids are characterized as activity-scoped with out-of-scope ids ignored rather than erroring.

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-changing the admission result (录取结果) for signup submissions, while explicitly NOT changing the delivery state (不改投递态). This distinguishes it from both the singular sibling review_signup_submission and the delivery-related report_signup_delivery, so an agent can route correctly without opening any schema.

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

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

Gives an explicit end-to-end procedure: fetch ids via list_signup_submissions → run with preview=true (no persistence) to show id/nickname/current status → only after the user explicitly confirms the roster run with preview=false. It also states a hard exclusion (不能跳过确认) and tells the agent that other cases should change reviewStatus and be handled separately.

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 supply idempotentHint=true, so the description carries most of the burden. It adds real value by disclosing the auth requirement and the eligibility states, but omits what actually happens on cancel — effect on existing signups/guests, whether it is reversible, and whether a confirmation is returned. There is also mild tension with idempotentHint=true, since it says an already-cancelled activity 'cannot be cancelled again' (error) rather than being a no-op.

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 eligibility constraint front-loaded and nothing superfluous. The telegraphic '登录;' prefix is terse but still readable.

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 full schema coverage and no output schema, the definition covers who, what, and the state precondition. It is still thin on the consequences of a destructive organizer action (fate of registrations, post-cancel visibility), which an agent may need before invoking.

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 activityId is already documented, so the schema does the heavy lifting. The description adds only a light ownership qualifier ('an activity I created') without any format or lookup guidance. 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 (取消/下线, cancel/take offline) and a scoped resource (我发起的某个活动 — an activity I created), which distinguishes it from sibling tools such as cancel_my_activity_signup. It does not name the sibling explicitly, so it falls short of a 5.

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

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

Gives clear preconditions: you must be logged in, and the activity must not already be cancelled or ended. This defines the usable state boundary well. It never points to an alternative tool for cancelling a signup versus cancelling an organizer's own activity, which keeps it below 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?

With no annotations, the description carries the full burden and does disclose two things the rubric credits: the auth requirement (login + alliance manage permission) and the blast radius (cancels only pending invitations; already-joined organizations are untouched). It omits reversibility (must the invitation be re-issued?), behavior on an already-accepted invite, and failure modes.

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

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

A single dense sentence with the gating constraint (login) front-loaded and zero filler; every clause carries information. Slightly compressed to the point that the verification instruction reads as a run-on.

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-parameter mutation with no annotations and no output schema, the description covers purpose, permissions, and effect scope, which is a reasonable minimum. It leaves an agent guessing about the return value and about what happens if the invitation is no longer pending.

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 both parameters are undocumented (linkId is a bare $ref to the allianceId string). The description only alludes to their meaning via '核实 linkId 与组织', which hints that linkId identifies the invitation and allianceId the organization, but supplies no format, source, or lookup guidance to compensate for the empty schema.

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

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

States a specific verb+resource (撤回联盟发出的加盟邀请 / cancel an alliance's outgoing join invitation) and adds a scope boundary that separates it from removal-type siblings: '只取消待接受邀请，不移出已加盟组织'. It never names the nearest alternatives (cancel_my_alliance_application, revoke_organization_member_invite, cancel_organization_alliance_request) explicitly, so an agent still has to reason about which cancel it wants.

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?

'【需要登录】須联盟 manage' plus '工作台核实 linkId 与组织后确认撤回' implies the context (an alliance manager working from the workbench) and a verify-then-confirm precondition. However there is no explicit when-to-use versus sibling cancellation/revocation tools and no statement of when NOT to call it (e.g. after the invite was accepted).

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

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

With no annotations supplied, the description carries the full burden and does so: login is required, authorization is limited to the initiating party, the action is irreversible, the invite disappears from the recipient's to-do list, and non-pending invites will not be retried. Those are the auth, preconditions, irreversibility, and side-effect facts an agent would otherwise have to guess.

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 compact and front-loaded: auth, then authorization scope, then irreversibility, then the parameter source, then the failure-state rules. The semicolon-separated telegraphic style is dense, but nearly every clause adds a distinct constraint, and no sentence is filler.

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

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

For a one-parameter mutation with no annotations and no output schema, the description covers the auth requirements, preconditions, reversibility, parameter provenance, and post-call effects. The remaining gap is small: it doesn't say what the agent should expect a successful response to indicate. Because no output schema exists, that is a modest omission rather than a blocking one.

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 has to compensate, and it does the most important part by telling the agent where inviteId comes from: get_collaboration_goal(include=invites). It doesn't restate the format or length limits, but those are already enforced by the schema (minLength 1, maxLength 40).

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 (withdraw a collaboration invitation) plus the exact scope: only the initiating party can do it, and only while the invite is still unanswered. That scope makes it clearly distinct from the sibling respond_collaboration_invite (the recipient's accept/decline path) and from cancel_alliance_invitation (a different resource).

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 names the conditions for use (only the target initiator, only unresponded invites) and the explicit exclusion: if the invite is already accepted, declined, or expired, do not retry; check the current state first. It also tells the agent to verify the recipient and confirm before acting, which is exactly the pre-call routing 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?

With no annotations, the description carries the behavioral burden and does well: it requires login, describes a preview-then-commit confirmation flow, and warns that no refund is issued and that tickets, annual passes, and online viewing benefits remain unaffected. It stops short of explicitly stating whether the cancellation is reversible or what the response contains.

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 economical, front-loading login and usage before the operational constraints. The semicolon-separated style makes it less scannable than it could be, but there is little wasted wording.

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 annotations, no output schema, and four undocumented schema parameters, the description covers the essential usage, scope, preview protocol, and key irreversible implications. It would be stronger with explicit return/error behavior and a clearer statement of reversibility, but it is sufficient 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 0%, so the description must explain the parameters, and it does for the non-obvious ones: preview first, then use the same parameters plus previewHash, consent=true, and preview=false. It leaves activityRef's expected reference format implicit, which is the main remaining parameter 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 gives a specific verb and resource: withdrawing the user's own offline activity signup and any pending-activation placeholder. It also scopes the action to this site's offline registration and explicitly separates it from canceling reminders, tickets/passes, or online viewing rights, which distinguishes it from neighboring cancellation 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?

It states the triggering condition clearly: use when the user explicitly cannot attend or is canceling. It also gives concrete exclusions and escalation paths for external forms, already checked-in users, and activities that have already started, plus the warning that canceling a reminder is not the same as canceling a registration.

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

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

With no annotations available, the description covers a lot: login requirement, state precondition, and the clarifying fact that it does not dissolve an already-established alliance. It does not say what happens to the withdrawn application record (status change vs. deletion) or whether the call is idempotent, which keeps it short of a 5.

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 tight clauses with no filler. The login requirement is front-loaded, followed by scope, then preconditions.

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 single-param mutation with no annotations and no output schema, and the description covers auth, precondition, exclusions, and one postcondition caveat. Only the response shape and record-after-withdrawal state are left unstated, 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?

Schema coverage is 0%, so the description has to supply the param meaning. It points the agent to get_my_alliance_application_state to obtain and confirm the application id, which outweighs the missing format details, although the id syntax still comes only from the schema's minLength/maxLength.

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 (withdraw my own alliance-creation application) and scopes it to applications that are still pending review. This clearly separates it from submit_alliance_application and get_my_alliance_application_state in the sibling list.

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

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

The description states the prerequisite (must be logged in), says to first read the user's status and confirm the application id, and explicitly excludes approved or rejected applications. The agent knows both when to call it and when not to.

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 idempotentHint=true; the description adds the materially important facts: login is required, cancellation is terminal and the need cannot be edited or reopened, and the exact error codes/messages for ownership and state violations. The 409 need_closed on repeat calls is consistent with idempotency (state unchanged) but usefully warns the agent to expect an error response rather than a silent success.

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

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

One dense line, front-loaded with the action and its terminality before the alternative and error codes. The semicolon-chained telegraphic style packs a lot in but is slightly clipped, and the '登录' fragment is terse to the point of being cryptic.

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 no output schema, it covers auth, irreversibility, the sibling alternative, and failure modes — essentially everything needed to call it correctly. It does not say what happens to dependent artifacts (matches, conversations) after cancellation, a minor residual 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, but the description adds a real constraint beyond the schema: needId must refer to a need owned by the caller (非本人403), which tells the agent this is not an admin-level cancel. It does not add format details for needId, so it stops short of 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 and resource ('本人需求取消' — cancel one's own need) and immediately qualifies it as a terminal state, which distinguishes it from sibling mutations like unpublish_need, delete_need, complete_need, and reopen_need. 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?

Explicitly routes the temporary-takedown case to unpublish_need, which is the key sibling ambiguity for a 'cancel a need' tool. It also gives concrete blocking conditions (not owner → 403, already completed → 409, already cancelled → 409) so the agent knows when this call will fail and why.

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

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

With no annotations, the description carries the full load and does well: it discloses the auth requirement, the manager role requirement, the read-before-write prerequisite, and the scope restriction. It does not say what an invalid/failed withdrawal returns or how the request state changes, which keeps it below a 5.

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 with the auth requirement bracketed up front and the scope exclusion last; every clause carries operational information and nothing is repeated from 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 two-parameter mutation with no annotations and no output schema, it covers auth, role, prerequisite lookup, and scope. Only failure/response behavior and the meaning of organizationId remain 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 coverage is 0%, so the description must compensate. It explains where linkId comes from ('先读组织联盟状态并确认本组织 linkId'), which is genuinely useful for a schema that self-references organizationId, but it says nothing about organizationId or the format/constraints of either identifier.

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, more importantly, the exact boundary: '只撤回待审申请，不退出已加盟联盟' (only withdraw pending applications, does not leave an already-joined alliance). That boundary is what separates it from the sibling leave_organization_alliance, though the sibling is not named outright.

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 preconditions and an ordered workflow: must be logged in, must be the organization's actual manager, and must first read the alliance status to confirm the linkId. It also states the negative case (already-joined alliances are out of scope), though no alternative tool is named for those cases.

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 carry only idempotentHint, yet the description adds substantial behavioral context: login requirement, preview-before-commit safety, that cancellation is not a refund ('取消非退款'), and that concurrent payment/close may result in an already-paid order where success must be read from the returned status. This meaningfully exceeds what the annotation provides.

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

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

Dense, front-loaded and free of filler; the login prerequisite and preview-then-confirm flow lead, followed by the concurrency/failure caveat. The single semicolon-chained sentence is efficient, if a touch packed.

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

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

For a mutating tool with no output schema, it covers the essential gaps: the confirm flow, idempotent reuse of previewHash, and guidance to read success from the returned status. It stops short of describing the response status fields, but 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 0%, so the description must explain all three params, and it effectively does: preview toggles preview vs. confirm, previewHash is the value returned from the preview step reused on confirm, and outTradeNo identifies the order. It compensates well, though the previewHash derivation and outTradeNo format are only implied rather than spelled out.

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 two-phase operation on a specific resource: preview '本人未付订单' then close the original order with previewHash + preview=false. It clearly belongs to the payment-order lifecycle, distinguishing it implicitly from read-only get_payment_order and from resume_payment_order, though it never names those siblings 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?

It gives an explicit call sequence: preview first, then re-issue the same params plus previewHash with preview=false to confirm. It also scopes who may use it ('本人', requires login) and warns of the concurrency exception. No explicit exclusion of siblings, but the when-to-use path 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 only declare readOnlyHint=true; the description goes well beyond that by disclosing that the tool returns named status codes (profile_incomplete, organizer_profile_required, no_published_product) and what each implies. Crucially it discloses a capability boundary — that SMS verification cannot be completed through MCP — which an agent could not infer from any structured field.

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?

Extremely dense and front-loaded — the precondition list comes first, then the remediation branches in the order an agent would encounter them. The telegraphic, semicolon-chained Chinese style packs maximum information but is slightly harder to parse on first read than a structured list 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 zero-parameter read-only gate with no output schema, the description covers everything an agent needs: the eligibility criteria it validates, the failure codes it emits, the remedy for each, and the follow-up tool. The only minor omission is the exact response shape, which is largely implied by the enumerated codes.

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 and the schema-coverage baseline of 4 applies. No parameter text is needed or missing.

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?

"办活动先查" plus the enumerated preconditions (bio/intro ≥10 characters, published product, organizer onboarding fields) states a specific verb and resource rather than restating the name. It also positions itself relative to siblings: it is the gate before create_organizer_activity, with create_product as a prerequisite branch. An agent can distinguish this 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?

Explicit sequencing instruction ("办活动先查" = check this first before launching an activity) and a routing table for each outcome: profile_incomplete → complete onboarding, no_published_product → create_product first, otherwise → create_organizer_activity. It even states a hard exclusion: organizer_profile_required requires App SMS verification and cannot be written via MCP.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces this by explicitly denying check-in writes and auto-registration/ticketing ('不会执行签到写入', '不自动报名或购票'). It additionally discloses a login requirement and the human-in-App verification flow (geolocation or on-site dynamic code), which annotations do not convey. Return format is not described, keeping it at 4.

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 is front-loaded and the sentences are dense but purposeful. There is minor redundancy between '只读' and '不会执行签到写入', but the extra emphasis is defensible given the misleading tool name.

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

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

For a read-only tool with no output schema, the behavioral picture (login, read-only, no auto-registration, App-only verification) is fairly complete. However, the 4-parameter surface with 25% coverage, particularly the legacy 'preview'/'previewHash' parameters, is left unexplained, leaving the agent guessing about non-required inputs.

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 25% — only 'consent' is documented, while 'preview' and 'previewHash' have no schema text. The description does not explain any parameter, offering only the vague hint '保留旧参数兼容'. At low coverage the description is expected to compensate, and it largely does not.

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

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

Despite a misleading name ('check_in') that implies a write, the description explicitly redefines the tool as a read-only status check plus an App resume entry ('只读本人活动签到状态和 App 续接入口'). This is a specific verb+resource distinction an agent can act on. It does not name a sibling tool, so it stays at 4 rather than 5.

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

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

The description states clearly when this tool applies (reading own check-in status) and when it does not (Agent/web/mini-program never perform on-site check-in; the user must do it in the App after completing their profile). The only gap is that it does not point to a specific alternative sibling such as check_activity_eligibility or get_activity_attendance.

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 supply destructiveHint=false, so the description carries most of the behavioral load and does so well: it discloses that the claim is irreversible, that it transfers an entire placeholder profile plus products and conversations, and that four distinct failure codes exist with a no-retry instruction. Minor deduction because the leading '登录' is ambiguous (does the caller need to be logged in, or does this perform a login?) and '不可逆' sits in mild tension with destructiveHint=false, though claiming transfers rather than deletes.

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 information-bearing: scope, irreversibility, error branches, and the follow-up call all appear in three short clauses. The telegraphic style and the ambiguous opening '登录;' cost it a point, since a reader must guess whether that is a precondition or an action.

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

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

For a two-parameter mutation with no output schema, the description covers the critical unknowns: irreversibility, the blast radius of the claim, and what to do on each failure code. It does not describe the success payload or where the token/creatorId pair must come from beyond the email link, which is a modest remaining 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 100% and the schema already explains both parameters, including the same source hints ('邮件链接 ?ct=<token>' and '/u/<creatorId>'). The description repeats the token origin but adds no syntax, format, or constraint 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?

The description names a specific verb and resource ('凭邮件ct token不可逆认领整份占位主理人资料/产品/会话') and explicitly scopes it as the whole placeholder creator account, not a single product code ('非单产品码'). That negation directly separates it from siblings like claim_product and claim_organization_profile, so 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?

It prescribes a sequence ('确认身份/token来源→认领→get_my_card') and gives explicit error branching: on ok=false handle invalid/not_found/claimed/self and do not blindly retry. It stops short of naming a concrete alternative tool for the single-product or organization-claim cases, leaving that comparison 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?

Annotations only declare idempotentHint=true and destructiveHint=false; the description adds substantive behavior beyond that — claiming mutually exposes contact details between the seeker and the introducer, the target's per-order consent still gates exchange, and no contact or payment is triggered automatically. The idempotency note ('重试同key') reinforces where the annotation matters, though failure modes and what previewHash is derived from remain unstated.

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?

Every clause carries operational content and the sequence is front-loaded starting with login and the prerequisite read. The semicolon-chained, telegraphic style is efficient but slightly compressed for a high-stakes commit step, so a reader must parse twice to separate preconditions from the confirmation payload.

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

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

For an 11-parameter, no-output-schema mutation with zero schema descriptions, the definition covers the workflow and the post-claim visibility consequences well. It stops short on the identifier fields, the previewHash provenance, and expected error/retry semantics other than same-key reuse, which are the gaps most likely to cause a malformed call.

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% across 11 parameters, so the description has to carry the load. It does explain the critical contract: anonymousSummary and relationship must be truthful/real, preview defaults to the validation pass, and confirmation requires preview=false with a matching previewHash plus consent=true, and that retries reuse the same idempotency key. The identifier parameters (id, targetUserId, targetContactId, proposalId, note) get no explanation at all, leaving roughly half the surface 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 conveys a two-phase claim workflow (preview then commit) on a network bounty and names the prerequisite lookup tool get_network_bounty, so the agent can infer this is the commit step of claiming. It never states the purpose in a single explicit sentence, but '接单' plus the preview/confirm sequencing distinguishes it from siblings like quote_network_bounty, preview_network_bounty_price and manage_network_bounty.

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 ordering is given: log in, call get_network_bounty first, fill anonymousSummary/relationship, preview to verify terms and fees, then re-issue the same call with preview=false, previewHash and consent=true. It also states the target still has to consent per order, which bounds what claiming grants. It does not contrast with quote_network_bounty or manage_network_bounty, so the when-not guidance is incomplete.

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 idempotentHint=true, so the description carries real weight and does: irreversible action, login required, per-value confirmation, fill-only-empty semantics, canFill=false fields skipped, filledCount potentially less than fieldKeys and must be reported honestly, plus the side effect that the organization will see the claim. The 'irreversible' warning is compatible with idempotency (re-runs fill nothing new) rather than 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?

No wasted sentences — every clause carries an operational constraint, and the irreversible warning is front-loaded. The telegraphic arrow-chain style is dense and takes effort to parse, but trimming it would lose real guidance.

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

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

There is no output schema, and the description compensates by describing the return-side signal (filledCount, canFill) and how to report partial results. Combined with the full workflow chain and mutation semantics, an agent has everything needed to call it correctly and safely.

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

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

Schema coverage is only 33% (only contactId documented), but the description compensates by specifying where contactId comes from, that fieldKeys must contain the complete set returned by list_my_organization_claims, and that accept must be true. It does not explain what each of the 11 enum field keys means, though the enum names are largely self-describing.

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 compound action (claiming pending organization data and backfilling it into one's own cross-form signup profile) with an explicit non-overwrite scope rule. It is clearly separable from siblings like list_my_organization_claims (the source) and submit_signup (the downstream step), which are named directly.

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: list_my_organization_claims to obtain id/fields, then this tool with all fieldKeys and accept=true, then get_signup_gaps, then submit_signup. It also imposes a hard prerequisite (login) and a mandatory UX condition (display each value and obtain confirmation) before calling, leaving little to inference.

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

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

Annotations already declare idempotentHint=true and destructiveHint=false, so the description's job is lighter. It still adds real behavioral context the annotations do not: a login is required, the claim transfers the product to the current account, and the product is published immediately with moderation happening afterwards (先过后审). Missing only failure behavior when a code is invalid or already consumed.

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 clauses, front-loaded with the login requirement and the core action, with no filler. The leading '登录;' fragment is a slightly awkward opener but costs almost nothing.

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, no-output-schema tool the description covers preconditions, source of the input, and the immediate post-claim side effect, which is what an agent needs to call it safely. It is only short of describing error/duplicate-code outcomes, which matters somewhat given the idempotent claim.

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 a single parameter and schema coverage is 100%, so the schema already documents claimCode fully. The description adds only the origin of the code (admin-issued), not format, length, or single-use semantics, so this is the standard baseline rather than added value.

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 (认领/claim) and resource (产品/product) plus the mechanism (认领码) and the source of the record (管理员/爬虫预录). That source detail separates it from create_product and from sibling claim tools such as claim_organization_profile and claim_creator_by_token.

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?

Makes clear this applies only to already-recorded products that someone else entered, and that the claim code normally comes from an admin, so an agent knows the precondition. It never names an explicit alternative (e.g. use create_product when no record exists) or states what to do with an invalid code, so guidance stops 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?

Annotations only declare idempotentHint and destructiveHint=false; they say nothing about persistence or cost. The description adds three things an agent could not infer: login is required, the call has real LLM cost, and it writes nothing to the database. It further sets expectations that category/tags/domain may come back null with OTHER as a normal fallback, which prevents the agent from retrying on a valid-but-empty result.

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 no filler; every clause (auth, cost, no-persist, null handling, workflow order, no-looping) earns its place. It loses a point for the run-on semicolon-chained formatting with no spacing, which makes it harder to scan than a short ordered list 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?

There is no output schema, so the description must explain returns — it does so partially by naming the returned fields (category/tags/domain) and the OTHER fallback. Combined with auth, cost, and the follow-up workflow, an agent has enough to call it correctly, though the exact response shape remains implicit.

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 carries per-field hints, including the 'write it concretely for better classification' guidance for description. The description adds no syntax, format, or constraint information beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource ('草稿发布前LLM分类') and immediately scopes it as a trial that does not persist ('不写库'). It names the downstream siblings it feeds into (create_product / update_my_product), so an agent can place it in the workflow without opening another 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 ordering: classify → user verifies → create_product/update_my_product, and notes those siblings already auto-classify. It also adds a negative rule ('勿循环试探' – do not probe repeatedly), which is exactly the kind of when-not guidance most definitions omit.

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

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

With no annotations, the description carries the full burden and does: it discloses authorization requirements, the cascade side effects, partial-skip semantics for foreign needs, and that the operation is irreversible with no rollback of already-unpublished/stopped items on later failure.

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

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

Front-loaded with the action and cascade, then prerequisite, then workflow, then caveats. Dense slash-delimited phrasing packs a lot in, but it remains scannable and no sentence is filler.

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

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

Covers auth, cascade, preview output counts, skip results, and irreversibility for a destructive 3-param tool with no output schema. Minor gap: it doesn't say what the committed result contains or how goalId is obtained, though sibling get_collaboration_goal covers lookup.

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

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

The schema already documents status enum values and the preview default, so the description's added value is the workflow meaning of preview (dry-run vs. commit) rather than restating types; it does not elaborate on goalId but that is self-evident.

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 the collaboration goal) and its cascade scope (unpublish own public recruit needs, stop task-series rules/pending periods), and explicitly contrasts with the sibling update_collaboration_goal which only changes status without cascading.

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 prerequisite (logged-in / goal owner), a mandatory two-step workflow (preview=true shows N needs / M rules / K periods, then preview=false after explicit confirmation), and the alternative path for other people's needs (skipped=not_your_need, author must call unpublish_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 idempotentHint=true and destructiveHint=false, so the baseline is low; the description still adds real behavior: archived leads are restored rather than duplicated, self or unavailable accounts land in 'skipped' without aborting the batch, and anonymous signups are skipped and counted. These partial-failure and state-restoration semantics are not derivable from the annotations or schema and materially change how an agent should interpret results.

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?

Every clause carries information — limits, idempotency, restore, skip behavior, content restrictions, next step — and the action plus the 20-item cap are front-loaded. Density comes at a cost: semicolon-chained fragments with no spacing make it slower to parse than necessary, though nothing is redundant.

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

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

For a 3-parameter mutation with no output schema, the description covers nearly everything an agent needs: auth prerequisite, batch cap, per-item skip semantics with reported counts, idempotency/restore behavior, and the natural next tool. It stops short of describing the exact shape of the result (e.g. collected vs. skipped counts and any per-lead identifiers), which an agent would still have to discover.

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 a 3 is the floor, and the description earns above it: it constrains note content (no questionnaire answers), constrains tags to activity markers only, and defines the eligibility rule for userIds (only signup entries with a userId, anonymous skipped). That is semantic policy the schema cannot express.

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: batch-collect up to 20 on-site users into the caller's own lead pool, with the limit spelled out inline. It never names the adjacent siblings (create_broker_lead for a single lead, import_broker_leads for file imports), so an agent must infer the difference from the verb '收' plus the userIds array rather than being routed 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?

It gives concrete operating context: requires login, applies to signup lists where only entries carrying a userId are taken, and points to scan_broker_matches as the follow-up step. It also issues a hard prohibition (do not copy questionnaire answers into note), which is genuine usage guidance. What is missing is an explicit statement of when to prefer this over create_broker_lead or import_broker_leads.

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 destructiveHint=false, so the description carries the real burden and does: login required, the moment author (and the replied-to user) receive notifications, the content is externally visible, and the user must confirm the text before posting. That last point is genuine pre-flight guidance not encoded anywhere in structured fields. Minor note: it says 1–500 characters while the schema's maxLength is 1000, so the stricter limit in prose is the one to follow.

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

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

Three bracketed, front-loaded blocks (precondition/mode, tool chain, cautions) with no filler sentences. Slightly terse and jargon-tagged, and the character-limit statement duplicates the schema while conflicting with its maxLength, which is the only small structural blemish.

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 mutation tool with no output schema and thin annotations, it covers auth, required inputs, ID sourcing, recipient side effects, visibility, and a confirmation step. The only omission is whether the created comment's ID is returned, which is not relevant without an output schema.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds effect-level meaning beyond the field docs: passing replyToCommentId means replying to that specific comment and triggers a notification to that person, while omitting it means a top-level comment. That behavioral difference is more than the schema's "不传 = 直接评论" phrasing conveys.

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 distinguishes the two modes via replyToCommentId, which separates it from publish_moment, like_moment, and delete_my_moment in the sibling list. An agent can tell what this does and what it is not 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?

Explicitly names the predecessor tools that produce the required IDs (list_moments_feed / get_moment) and routes a distinct task (replying to received interactions) to list_moment_notices first. It also states the login precondition, so the agent knows when the call will fail rather than succeed.

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 single idempotentHint annotation: login requirement, no automatic outreach/invitation, no overwriting of real person profiles, partial-success semantics, idempotency-key reuse rules, and the constraint that only a success receipt permits claiming the contact was saved/published. This is the kind of edge-case disclosure an agent cannot get from 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?

The critical gate (login + mandatory user confirmation) is front-loaded in brackets, which is the right ordering. The remainder packs several distinct branches into dense run-on clauses with ambiguous antecedents ('沿用原token/key'), which slows parsing but each 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?

For a 2-parameter, no-output-schema mutation tool, the description covers prerequisites, mutation side effects, idempotent retry behavior, partial-failure states, and the claim-only-on-success rule — everything an agent needs to invoke it safely. Return-shape detail is unnecessary given receipt semantics are already summarized.

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 both parameters — and it does: previewToken is tied to the confirmed preview, idempotencyKey is tied to reuse-on-retry vs. new-key-on-plan-change. Minor gap: no format/opacity guidance (e.g. token lifetime, key length) and the mention of 'resumeReceiptId' refers to the sibling preview tool's parameter, which could momentarily confuse an agent about this tool's 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: '按previewToken保存私人人脉及已选公开范围', and bounds it with '不自动联系/邀请或覆盖真人档案'. It also makes clear the tool is the commit step of the preview_network_contact_intake flow, so an agent can separate it from the preview sibling. The Chinese-only, jargon-dense phrasing ('PARTIAL', '原token/key') slightly blunts immediate comprehension.

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 preconditions ('【登录；必须先经用户核对具体预览并明确确认】') and explicit alternative routing: to change the plan, re-run the preview with resumeReceiptId, then submit with a new key. It also spells out the retry branch (unknown/PARTIAL → reuse same token/key, skip completed items) and the ambiguous case (contactId + errorCode = not done).

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 only destructiveHint=false supplied, the description carries the load well: it states a login requirement, declares that writes default to preview, specifies the exact commit contract (same params plus previewHash, consent=true, preview=false), and adds semantic caveats that accepting does not add the user to the WeChat group and venue confirmation does not imply payment. These are exactly the side-effect and state-expectation facts an agent cannot get from the annotations or schema.

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

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

The description is short and front-loaded by action, with dense semicolon-delimited clauses and no filler. The compression is near the edge of cryptic — the opening '登录;' fragment and inline field lists demand careful parsing, but nothing is redundant.

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

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

For a 14-parameter, no-output-schema, minimally annotated multi-action tool, the definition covers auth, the preview/commit flow, decision semantics, and what the actions do not change. What remains missing is error/failure behavior and what a preview response returns (e.g., where previewHash comes from), which matters given the absence of an output schema.

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

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

Schema description coverage is 0% across 14 parameters, so the description must compensate, and it mostly does: it explains kind/box/status filtering, the two cursor fields for mixed lists, requestId for get, the decision enum including organizer_confirm's special meaning, and the previewHash/consent/preview triple. `note` and `limit` are never mentioned, and pagination termination or cursor direction is unstated.

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 the resource (群与场地申请) and enumerates concrete verbs via the action modes: list paginates by kind/box/status, get reads by requestId, respond executes decisions. That is far more specific than a title restatement. It does not, however, distinguish this tool from near siblings such as manage_my_community_resource or contact_community_resource, so an agent must infer the boundary.

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?

Per-action conditions are given: mixed lists require groupCursor/venueCursor, get requires requestId, and decision values map to kind. The organizer_confirm branch carries an explicit precondition (only after offline agreement, to mark as finalized), and the write path states the preview-first workflow. No explicit when-not-to-use or sibling alternative is 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?

Annotations only supply destructiveHint=false, so the description carries most of the behavioral burden and does so: it explains the two-sided confirmation model (author and claimer each confirm, both required), points to authorDone/claimerDone as the state to inspect, requires login, and gives concrete error-code semantics with no-retry instructions. That is exactly the operational context annotations do not provide.

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

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

Very dense and front-loaded with the action and constraints, and every clause carries real information (state fields, error codes, workflow). The telegraphic semicolon style and leading '登录' make it slightly harder to parse than a plain first sentence would, which keeps it just short of a 5.

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

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

For a two-parameter mutation with a thin annotation set and no output schema, the definition covers everything an agent needs: login requirement, eligibility, the two-party completion model, the state fields to check, the preceding read tool, and terminal error cases. Nothing material is missing.

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

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

Schema description coverage is 100% and both parameters are documented there, so the baseline is 3. The description only indirectly contextualizes conversationId by tying the operation to a '认领会话' (claimed conversation); it adds no format, sourcing, or validation detail beyond the schema.

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

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

States a specific verb and resource with scope: '只对认领会话声明本人已完成' – it marks the caller's own side as done, and only within a claimed conversation. It also implicitly separates itself from read-side siblings (get_conversation_needs) and from cancel_need/reopen_need, so an agent can pick it without opening the schema.

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

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

Gives an explicit prerequisite (must be a claimed conversation), an explicit precondition ('先确认事实' – verify the facts first), and an explicit call sequence: get_conversation_needs → confirm → complete_need. It also lists when-not-to-act: 403 non-participant and 409 for no claim / already completed / need closed, with '勿重试' (do not retry) guidance.

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

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

Annotations only declare idempotentHint=true and destructiveHint=false; the description adds real behavior beyond that — a write of the completion timestamp, persona-conditional requirements (FOUNDER needs product and bio, intro optional), and that validation failure returns an error rather than silently completing.

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 and front-loaded — completion semantics first, then validation rules, then workflow. The arrow-chain shorthand is efficient but sacrifices some readability, and the leading '登录;' fragment adds little.

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 parameterless state-transition tool with no output schema, the description covers prerequisites, validation gates, error handling, and the correct call order. What happens to the returned payload is unspecified, but that is minor 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?

Zero parameters, so there is nothing to document and the schema coverage is vacuously complete. The persona preconditions mentioned are context for failure modes, not inputs, so baseline 4 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: mark onboarding complete and write a completion timestamp, with persona-based validation rules. It distinguishes itself from the sibling get_onboarding_status by assigning that tool the read/inspect role. Slightly cryptic opening ('登录;') blurs the first clause.

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: get_onboarding_status → fill gaps → confirm → complete_onboarding, plus a clear negative instruction not to blindly retry on incomplete-data errors. No explicit exclusion cases, but the sequencing is unambiguous.

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

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

Annotations only declare destructiveHint=false, so the description carries most of the burden and does so well: it discloses the auth/role requirement, the DRAFT-only state gate, and the two-step preview→commit protocol bound by a previewHash. It also flags a security-sensitive behavior (CDKey values must not be passed through the model) and the option to retain existing prize inventory instead of re-entering it. Gaps remain on failure/rollback behavior and what a successful save returns.

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

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

The description is short, semicolon-delimited and front-loads the state gate before the procedure, with no filler sentences. The telegraphic style ('CDKey勿给模型') is efficient but slightly cryptic for a non-native reader, and the ordering of the inventory hint at the end feels appended.

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 write tool with a deeply nested config object, 0% schema description coverage and no output schema, so the description should explain more of the payload shape. It covers the orchestration (preview, hash, consent) and the CDKey policy well, but leaves requirements, requireAppCheckin, prize fields and activityRef unexplained. An agent could follow the save protocol but would be guessing at the config contents.

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 explain five parameters; it clarifies the interaction among preview, previewHash and consent, and hints at cdkeys versus reuseFrom in the prizes array. However, activityRef, config.title, config.rules, config.requirements and requireAppCheckin receive no semantic explanation anywhere. It compensates for the trickiest parameters but leaves the bulk of the nested config 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 opens with prerequisites ('登录/主办方;仅DRAFT') and a workflow rather than stating plainly that it configures a raffle draft for an activity. The verb 'save' (保存) and the DRAFT restriction imply a write to a draft raffle, but the actual purpose must be inferred from the tool name/title. It is distinguishable from get_activity_raffle or act_activity_raffle only indirectly via the preview/save protocol.

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 concrete procedure: preview first to verify the configuration, then re-submit the same parameters plus previewHash, consent=true and preview=false to save. It also states the hard precondition (logged in as organizer, activity must be in DRAFT) and a policy exclusion (CDKeys must not be handed to the model and must be configured by the person in the App). No sibling tool is named as an alternative, which keeps 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?

Goes beyond the annotations (idempotent, non-destructive) by disclosing the legal/identity semantics: identityVerified=false, only an account/name declaration is on file, and this is not a verified real-name check or formal e-signature. That is high-value context the agent could not infer elsewhere. It stops short of describing repeat-call behavior, which the idempotentHint already covers.

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 usage prohibition leads, followed by parameter constraints and the caveat. Every clause is operative and nothing is repeated from the schema or annotations.

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 confirmation/mutation tool with no output schema, the critical constraints (user-in-person confirmation, server-sourced revision/hash, non-verified identity status) are all present. The only gap is the unexplained requestId, which an agent must supply but cannot derive from the description.

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. It usefully specifies that revision and documentHash must come from the server and that legalName is optional, self-provided, and must not be guessed. It says nothing about requestId's role or acknowledged's const-true constraint, leaving two of five parameters undocumented anywhere.

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

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

States a specific action: confirming the current version of a cooperation document, with server-provided revision/documentHash. An agent can tell this records an acknowledgment rather than negotiating or signing, though the title and description don't explicitly route against siblings like kickoff_cooperation or respond_cooperation_proposal.

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 hard exclusions: only after the user personally views the version and explicitly confirms, never auto-confirm, never confirm on another party's behalf. This is exactly the precondition an agent must respect before calling a confirmation tool.

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

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

Beyond the thin annotation (destructiveHint=false), the description discloses meaningful behavior: a safe default preview of the real resource and opener, a hash-gated confirmation step, manual relay for cloud users, and the important caveat that establishing a conversation does not mean acceptance, group entry, or confirmed availability. This is substantial added context, though it doesn't cover failure modes or rate/permission constraints.

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

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

The description is dense and semicolon-structured, front-loading the login precondition and the preview default before the commit instructions and caveats. Every clause carries information, though the compressed run-on style 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?

For a 12-parameter mutation-with-confirmation tool with no output schema and minimal annotations, the description covers the workflow, most parameter meanings, the preconditions, and the practical caveat about conversation establishment. It is close to complete; only return-value expectations and edge-case behavior remain unstated.

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 coverage across 12 params, the description must carry the burden and largely does: it explains targetUserId's meaning for groups, and activityId, startsAt/endsAt (timezone-aware), headcount, and spaceName for venues, plus previewHash/consent/preview for the commit step. Only kind (enum semantics) and id are left to the schema, so the compensation 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?

The description establishes a specific resource and action through the mechanics: kind distinguishes group vs venue, targetUserId identifies the owner/admin/invitable person, and the preview→commit flow makes clear this is a contact/introduction request. The core verb 'contact the group owner or venue provider' is never stated as a sentence, so an agent infers the purpose from parameters rather than reading it directly.

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 procedural usage path: default preview (preview=true), review the message, then resubmit the same params with previewHash, consent=true, preview=false. This tells the agent exactly how to use the two-phase flow. It does not compare against siblings such as community_resource_requests or request_ecosystem_venue, so the alternative-selection guidance is absent.

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 idempotentHint=true and destructiveHint=false; the description goes well beyond that by disclosing the real side effect ('会真实开聊/发送'), the no-quota-limit fact, the crucial nuance that claiming is idempotent but the message is resent on every call, and the no-retry rule for 400/404/409/429. The idempotency nuance refines rather than contradicts the annotation, since it scopes idempotency to the claim and not the message.

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 core action are front-loaded, and every clause carries information (side effect, quota, idempotency, error codes, workflow). The telegraphic semicolon/arrow style packs a lot into a small space but slightly reduces readability compared with 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?

With no output schema and only two parameters, the description still covers prerequisites (login), side effects, quota, error-code handling, and the full upstream/downstream tool chain. An agent has everything needed to call it correctly and to know what to do afterwards.

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: that the ≤2000-char message is a real outbound first message that will be re-sent on every invocation even though the claim itself is idempotent. It also tells the agent to confirm the needId target before calling, which is behavioral rather than schema-level guidance.

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: contact the author of an active ('在架') need and claim it ('联系在架需求作者并认领'). It distinguishes itself from siblings by naming the surrounding chain (get_need before, get_conversation_needs/send_message after, complete_need by both parties), so an agent can tell it apart from create_need, send_message, or start_conversation 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 gives an explicit invocation chain 'get_need→contact_need→get_conversation_needs/send_message→双方complete_need', and the error mapping '本人400' functions as a when-not (do not contact your own need). It also states the precondition '先确认对象' (confirm the target first) and the login requirement, leaving little to inference.

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

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

Annotations only carry destructiveHint=false, so the description does the heavy lifting: it discloses the permission requirement, the ownership side effect (caller becomes 负责人), automatic employee enrollment, blanket authorization, and — most valuably — that creation and alliance-joining are two separate non-atomic steps, plus a safe recovery path. It does not say what happens to a half-created org if step two fails.

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 gate, then the created-side-effects, then the failure-recovery rule — a sensible priority order with little filler. Sentences are dense but each carries a distinct operational instruction.

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?

Auth requirements, side effects, and the non-atomic two-step workflow are well covered, which is the hardest part of this tool. However, with 10 parameters at 0% description coverage, a nested terms object, and no output schema, the definition leaves the agent unable to construct a correct call without outside knowledge.

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% across 10 parameters including a nested terms object, and the description only gestures at '组织字段/协议' without mapping to any parameter. Nothing explains joinPolicy, visibility, investorEnabled, or the non-obvious spaceModules minItems=2 constraint, so the agent must infer everything from enums and defaults.

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 an alliance-owned organization) and adds scope detail — the creator becomes the owner and the org is created under an alliance. It is distinguishable from siblings like create_organization and attach_alliance_organization through the '联盟自有组织' framing and the two-step flow note, though it never names those siblings 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 a clear precondition (login + alliance manage permission) and an explicit failure path: on error, check list_my_organization_memberships for an already-created org and decide whether to attach rather than retrying. Missing an explicit statement of when to prefer create_organization over this tool for standalone orgs.

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 destructiveHint=false, so the description carries the real burden and does so: login is required, no deduplication happens server-side, and the phone-attribution rule (missing phone cannot attribute a later signup; claimedUserId non-empty means attributed) is spelled out. It even discloses a privacy behavior — only the last four digits of the phone are returned — which the agent cannot learn from any structured field.

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 login requirement and purpose, then the workflow chain, then caveats — good ordering with no filler sentences. The telegraphic phrasing (e.g. 已在站内且填手机则claimedUserId非空即归因) is dense enough that it takes a careful read, which slightly hurts 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 10-parameter mutation with no output schema, the description covers purpose, prerequisites, side effects, sibling routing, follow-up chain, and even the return shape (last four digits only). What it lacks is per-field semantics for the eight undocumented business fields, which is the main remaining gap for a tool of this complexity.

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

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

Schema description coverage is 0% across 10 parameters, so the description must compensate, and it only really explains phone (pattern implied by the attribution discussion) plus the count of ten fields. Name, title, company, city, tags, note, wants, canOffer and wechat get no meaning, constraints, or intended use from the description; an agent cannot tell which of them drive matching or attribution.

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

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

States a specific verb and resource — 新增站外线索 (create an off-platform lead) — plus the notable detail that it supports ten fields, which matches the 10-property schema. It actively distinguishes itself from the sibling import_broker_leads, so an agent can tell create-vs-import apart 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?

Explicit when-to-use routing: single manual entry here versus batch/merging imports via import_broker_leads 按手机合并, and an explicit when-NOT-to-repeat warning (服务不去重，重调重复创建). It also gives the down-stream chain create_broker_lead → scan_broker_matches(leadIds=[id]) → create_broker_match, which tells the agent what to do immediately after success.

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 idempotentHint/destructiveHint, it discloses that both sides' leads are set worked=true and that this affects 分账, that execution is per-item with failures not aborting the batch, and that duplicate pairs are treated symmetrically and idempotently. The worked=true side effect is exactly the kind of behavior an agent could not infer from annotations, and it does not conflict with destructiveHint=false.

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

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

Front-loads login, confirmation and the 20-pair cap, then workflow, then semantics, then safety. Dense semicolon-chained clauses in one block make it slightly harder to scan than a short bulleted structure, 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 single-parameter batch mutation, it covers preconditions, ordering relative to siblings, per-item failure behavior, idempotency, side effects with billing impact, and content rules for reason. No output schema exists, but nothing needed to invoke 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 already 100%, yet the description adds meaning: bUserId is for in-site users not yet in the pool (service layer auto-collects first), and reason must be written in plain human language with no scores because it is shown verbatim on four ends. It omits goalId entirely, so it does not fully cover the payload.

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 batch scope (最多20对) and where it sits in the broker flow. An agent can tell instantly that this creates broker match pairs in bulk, distinct from scan_broker_matches (discovery) and introduce_broker_match (downstream action).

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

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

Gives an explicit pipeline: scan_broker_matches → 用户确认 → 本工具 → get_broker_intro_scripts (off-platform send) / introduce_broker_match (in-platform group). It also names the precondition (user confirmation) and an expletive exclusion: 勿拿来试跑 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?

With only destructiveHint=false in annotations, the description carries the burden and does so well: login requirement, persistence of the created entity, initiator assignment, non-idempotency/retry hazard, and the returned id. This is exactly the operational context an agent needs before a mutating 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-loaded with the login gate and purpose, then the retry hazard, then the workflow — sensible ordering. The semicolon-chained clauses are dense but every one carries information; nothing is filler.

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

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

No output schema exists, but the description explicitly states what comes back (id, reusable with get_collaboration_goal/create_collaboration_task). Auth, idempotency, and pre-conditions are covered; the only real hole is what to put in title and intent.

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

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

Schema description coverage is only 33% (only dueAt is documented), so the description needed to compensate and does not. Neither title (2–60 chars) nor intent (max 2000 chars) is explained in terms of what belongs in them, and the create-vs-update semantics of dueAt(null clears, omitted preserves) are left entirely to 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?

Specific verb + resource (create a persistent collaboration goal) plus the side effect that the caller becomes the initiator. It positions itself in the lifecycle by naming get_my_work as a pre-check and get_collaboration_goal/create_collaboration_task as downstream consumers. It does not explicitly contrast with update_collaboration_goal, but the intent 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?

Gives a concrete precondition (check existing goals with get_my_work first) and a clear when-not-to-act rule (do not auto-resend after ambiguous results or timeouts; no durable dedup key). No explicit exclusions against sibling creation tools like create_collaboration_task, which keeps it 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?

The single annotation (destructiveHint=false) says almost nothing, and the description more than compensates: it discloses the notification side effect on assignment, the auth requirement, the absence of a durable idempotency key, and an explicit no-auto-retry protocol (re-read current state instead). That is exactly the operational 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?

Dense but front-loaded: auth, then the create/assign semantics, then the retry hazard and verification tool. Every clause is actionable; only the retry guidance repeats the same idea twice (结果不明或超时 / 不要自动重发).

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 and only a weak annotation, the description covers auth, side effects, idempotency and post-call verification. It never says what a successful call returns (e.g. the task id), which is why it points to get_collaboration_goal rather than stating the result shape.

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

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

Schema coverage is only 20% (only dueAt is documented), so the description must carry the load, and it explains the least obvious parameter: assigneeId omitted means self, otherwise it must be a goal collaborator (and triggers a notification). goalId/title/detail are left to their names and maxLength constraints.

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 and scope: create a task inside a collaboration goal (独行录目标中创建任务), plus assignment behavior. It does not distinguish this from the very similar siblings create_collaboration_tasks (plural, batch) or create_direct_collaboration_task, so an agent must infer which one to use from name alone.

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

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

Gives concrete preconditions (login required; only call after the user authorizes assigning to that person; assignee must already be a collaborator of the goal) and names a companion tool to run before and after (get_collaboration_goal). It lacks any explicit when-not or comparison against the plural/bulk 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?

Only destructiveHint=false is supplied by annotations, and the description fills the real gap: creation is non-atomic ('前成功不因后失败回滚'), results come back bucketed as created/failed, every task pushes a notification to its assignee, login is required, and there is a practical cap rationale. These side-effect and partial-failure semantics are exactly what an agent cannot infer from the schema or 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?

Extremely dense but front-loaded — login and batch scope come first, then the preview workflow, then failure semantics, defaults, and preconditions. Every clause carries information, though the telegraphic semicolon chaining makes it slightly harder to parse than prose 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 3-parameter mutation tool with no output schema, this covers everything an agent needs: auth requirement, batch cap, preview-vs-commit workflow, non-atomic failure behavior, result shape, notification side effects, and assignee defaulting. Nothing material is left to guesswork.

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% and the description adds genuine meaning beyond it: preview=true is framed as a permission/member check rather than a dry-run flag, and assigneeId defaults to the caller with a non-member precondition. The ≤10 limit and the preview return shape are already in the schema, so some repetition exists.

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 with a clear scope: batch-assign tasks under the same goal, capped at 10. It implicitly distinguishes itself from the singular create_collaboration_task sibling through '批量', but never names that sibling explicitly, so an agent must infer the single-vs-batch split.

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?

Strong operational guidance: preview=true to verify permissions and target members before confirming, preview=false to actually create, plus a prerequisite rule (invite non-members via invite_collaboration_member first) and a social rule (ask about merging when one person exceeds 3 tasks). What's missing is explicit routing versus the singular or direct-collaboration creation 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?

注解已声明 idempotentHint=true 与 destructiveHint=false，安全画像已有覆盖。描述额外补充了重要行为：一人一家（唯一性约束）、立即公开、触发异步处理，以及 slug_taken 时换 slug 的错误恢复策略，这些确实超出注解范围。但未说明异步处理的产物是什么、公开是否可撤回。

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

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

两句话，先写登录与确认前提，再写唯一性/公开/异步等关键行为，最后用箭头链路收尾，信息前置且紧凑。箭头链式写法略带电报体风格，但无冗余句子。

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

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

对一次 9 参数、会异步触发公开状态变更的写操作而言，描述覆盖了前置条件、唯一性、错误恢复和后续步骤，但未提及异步完成后如何查询结果（如 get_my_company / get_onboarding_status 之外的确认方式），也无输出 schema 可依赖。

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

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

schema 描述覆盖率已达 100%，9 个参数中 8 个为可选且均有中文说明，基线即为 3。描述仅额外点明 slug 冲突的处理方式（slug_taken 换 slug），对必填的 slug/name 语义没有超出 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?

描述以具体动词+资源开头（"创建/更新本人公司"），并说明了关键范围限制（"一人一家，立即公开且触发异步处理"），这将其与 update_my_company、create_organization 等同级工具区分开来。不过 "创建/更新" 的双重表述让主要操作（插入还是更新）略显模糊。

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?

描述给出了明确的前置条件与顺序（"登录；确认后"），并提供了工作流链路 read_my_profile→确认资料→create_company→complete_onboarding，能有效指导代理何时调用以及调用顺序。缺少的是何时不应调用（已有公司时应改用 update_my_company）的显式说明。

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

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

Goes well beyond the lone destructiveHint=false annotation: discloses that login is required, that the recipient is notified but notification does not imply acceptance, that execution re-validates mutual visibility, blocking, status and quota, and that auto-filling the contact from the login phone/profile is forbidden. These are exactly the side-effect and failure-mode facts an agent needs before committing a write.

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 with almost no filler, but it is a single semicolon-chained paragraph that front-loads the login tag rather than the action, and interleaves scoping, consent flow, and contact rules without ordering. Information-to-token ratio is high; parseability is not.

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 and thin schema descriptions, it covers the preview/execute contract, consent, contact-sharing constraints, recipient notification, and execution-time re-validation. Gaps remain around what the preview returns, duplicate-request behavior, and quota specifics, but nothing that would cause a wrong invocation on the happy path.

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

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

With only 22% schema description coverage across 9 parameters, the description carries most of the semantic load and does so for the critical ones: preview/previewHash/consent form a described handshake, activityId/organizationId are explained as mutually exclusive scoping with an all-empty public default, and contact is tied to shareContactConsent. targetUserId and the previewHash provenance (presumably returned by the preview call) are left implicit, which keeps it short of a 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?

The description never states plainly that it sends a connection/communication request to a target user; the action is only inferable from the title and from side remarks like "会通知对方，不代表接受". It also opens with a login precondition rather than a purpose statement, so the agent must reconstruct the verb+resource from surrounding clues.

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?

Strong two-phase guidance: default is preview, and execution requires re-calling with identical params plus previewHash, consent=true, preview=false. It also states the activityId/organizationId mutual-exclusivity rule and that omitting both means public scope. It does not, however, contrast itself with close siblings such as create_quick_contact_request or respond_connection_request.

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 carry destructiveHint=false, so the description does the heavy lifting: it declares the link revocable, expiring (1–365 days, default 7), a frozen snapshot, and that the plan's own visibility is unchanged. It also describes the recipient's side — link holders can read the body and can express interest after phone verification — which is behavioral context unavailable anywhere in 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?

Front-loaded with the gating condition, then consequence ('won't make private plans public'), then recipient behavior, then the pre-creation confirmation caveat. Dense but every clause carries decision-relevant information; only the expiresInDays restatement is redundant 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 thin annotations (a single hint), no output schema and undocumented parameters, this covers a lot: effects, lifetime, revocability, audience, and caution. Gaps remain — what the tool returns (the link itself?), whether the caller must own the plan, any cap on simultaneous shares, and the planId semantics.

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% with two parameters, so the description must compensate and largely does not. planId is never mentioned; the share's target is only implied by '方案'. The expiresInDays range and default it restates (1–365, 7) are already fully encoded in the schema (minimum/maximum/default), so that sentence adds no new 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?

States a specific verb and resource: creating a revocable, time-limited 'frozen' share link for a cooperation plan, with the explicit scope 'only when the user explicitly requests a public link'. The 'does not turn a private plan public' clause further bounds what the tool is. It stops short of naming its close siblings (preview_cooperation_share, list_cooperation_shares, revoke_cooperation_share), so the distinction is inferable rather than 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?

Gives a clear trigger condition ('only when the user explicitly requests a public link') plus a pre-check ('the user should confirm the content is suitable for sharing before creating'). What is missing is a pointer to alternatives — e.g. use preview_cooperation_share first, or revoke_cooperation_share to undo — even though those siblings exist in the same namespace.

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 single annotation: login requirement, self-assignment default, notification on assigning to others, authorization requirements for person and content, server-side relationship verification, a 50-per-Beijing-calendar-day rate limit, and the absence of a deduplication key with timeout handling instructions.

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

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

The description is dense and front-loaded with the most critical information (login requirement, core action). Every clause carries new information, though the run-on semicolon-separated style is slightly harder to scan than distinct 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 the tool's complexity (5 parameters, mutation, no output schema), the description is complete: it covers authorization, notifications, rate limits, verification steps, and retry behavior, and explicitly notes the response shape (goalId=null). 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?

With only 20% schema description coverage, the description compensates well by explaining assigneeId (defaults to self, notifies others) and organizationId (organization label with server verification). Title and detail semantics are left to the schema constraints, which is acceptable given their straightforward nature.

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 creates/assigns a task directly without attaching a goal ('不挂目标直接派任务'), distinguishing it from goal-attached task creation. It names the verb (派任务), the resource (task), and the key differentiator (goalId=null).

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

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

It provides explicit workflow guidance: use list_collaboration_task_assignees to find people, use list_collaboration_tasks to verify, and query current state after timeout instead of retrying. However, it doesn't explicitly name the sibling create_collaboration_task as the alternative when a goal attachment is desired, though '不挂目标' implies it.

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

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

Annotations only supply destructiveHint=false, so the description does the heavy lifting and delivers genuinely useful traits: login required, public visibility of the recruitment to all collaborators, and critically, no request deduplication — repeated calls create duplicate posts. It stops short of describing failure/error behavior or rate limits, which keeps it at 4 rather than 5.

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?

Semicolon-delimited fragments with no filler — every clause carries a constraint, warning, or routing rule. The ordering is slightly off since it opens with a login prerequisite rather than the purpose, but it is dense and readable.

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 public side effects, it covers prerequisites, the duplicate-post hazard, type selection, and the downstream workflow, which is close to complete. The main omissions are what the call returns (no output schema exists) and any explanation of the required goalId parameter.

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

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

Schema coverage is 75%, so the baseline is 3. The description reinforces the COLLAB default for `type` and adds a quality instruction for title/detail ("先确认title/detail原文"), but goalId has no explanation in either the schema or the description, so the remaining gap is not compensated.

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 communicates that this creates/posts a recruitment need tied to a goal ("重复调用重复发帖", "目标合作人均可公开招募") and clearly separates it from create_need ("其他对象需求用create_need") and from the GIG type. The plain verb+resource statement is carried mostly by the title, and the description leads with a login prerequisite instead of the purpose, which keeps it just short of a 5.

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

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

It gives explicit when/when-not rules: default to COLLAB and do not misuse GIG, use create_need for other-object needs, and it prescribes the follow-up workflow (get_collaboration_goal(include=recruits) to verify claims, then invite_collaboration_member). Alternatives and the routing condition are named outright, so 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 carry only destructiveHint=false, so the description rightly does the heavy lifting: management permission required, no sending on your behalf, no audience expansion, private-activity preconditions, and re-verification of identity/phone/audience at fill time. It also discloses the two-step preview/previewHash confirmation and that changes require re-confirmation — rich context beyond what annotations provide.

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

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

Front-loads the permission gate and purpose, then layers constraints and the confirmation workflow. Dense but every clause adds a real behavioral constraint; the composition is a bit packed but not padded.

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-destructive link-creation tool with a preview/confirm workflow, the definition covers auth, preconditions, safety traits, and the two-step confirmation. With no output schema needed here, the remaining gap is only the absence of explicit sibling differentiation.

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

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

Schema coverage is 0%, so the description must compensate and largely does: it explains targetUserId (required for private activities, requires existing audience eligibility) and the previewHash mechanism (same params + hash, preview=false, re-confirm on change). preview's default is also implied. activityRef itself is not elaborated, which keeps it from a 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 (准备...填写链接 / prepare a guest-profile filling link) with scope: 通用/定向 links, 不代发、不扩大受众. This distinguishes it from send_guest_invite_now by noting it doesn't send. However, it never explicitly names or contrasts with the very similar sibling link creators (create_guest_invite_link, create_guest_open_link).

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: private activities need targetUserId and pre-existing audience eligibility, targeted links go only to the individual, and it doesn't send or expand the audience. The preview→confirm flow is spelled out. Missing is an explicit 'use create_guest_open_link instead when X' routing against the two other link-creation 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 destructiveHint=false, so the description carries the real behavioral load and does: login and organizer role required, the link is a 14-day secret key, each call mints a new link while old cards stay valid for their lifetime, and the link must never be shared to groups or public pages. This is exactly the security and lifecycle context an agent needs before creating a credential-bearing link.

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 access tag and purpose, then constraints, with no filler sentences. It is dense and semicolon-chained, which slightly hurts scanability but every clause carries distinct 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 two-parameter tool with no output schema, the description covers workflow, prerequisites, link lifetime, idempotency behavior, and sharing restrictions — nothing material is missing for correct invocation.

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