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.