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.