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

Annotations declare readOnlyHint=false and idempotentHint=true; the description explains why by stating that reading tasks idempotently backfills cycle periods and is "非纯只读" — context the annotations alone cannot convey. It also discloses the login requirement and the 50-item cap on invitations, all beyond structured data and consistent with the annotations.

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

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

It is front-loaded with the login requirement and the core purpose, and every clause carries routing, pagination, or behavioral information rather than filler. The density is high and the semicolon-chained run-on style hurts scannability, but the length is justified for an aggregator with this many routing rules.

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 adequately describes return contents (goals with total, tasks, invitations), pagination via goalOffset/nextOffset, caps, and the non-read-only backfill behavior. The only real gap is the undocumented includeArchived parameter, which is minor against the otherwise thorough coverage.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden. It explains goalOffset for pagination and the total it returns, and implies the invitation cap ("邀请最多50"), but it never addresses includeArchived and only loosely maps to limit. Partial compensation, so a baseline 3 rather than higher.

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

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

The description enumerates exactly what the tool returns — collaboration goals, the caller's own dispatch tasks, and collaboration invitations awaiting response — giving an agent a concrete picture of the resource bundle. It also explicitly distinguishes itself from get_my_dispatch ("不读/标记安排，另用 get_my_dispatch") and from the goal tools, so it is separable from siblings 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 routes the agent explicitly: use get_my_dispatch for arrangements, don't call goal tools when goalId=null, use get_collaboration_goal to view a goal, list_collaboration_tasks when reachingLimit, set_collaboration_task_status to report, and respond_collaboration_invite to respond. This is explicit when-to-use / when-not-to-use / alternative guidance across multiple sibling tools.

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