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

Annotations already mark readOnlyHint, idempotentHint, and destructiveHint false, so safety is covered. The description adds crucial behavioral context: it requires login (【需要登录】), explains that participation is an array (not a single value), warns about pagination using nextCursor and null as end, and clarifies the window default. These are beyond the annotations and help the agent call correctly.

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

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

The description is well-structured with bold section headers (【需要登录】【何时用】【组合链】【口径/坑】) making it scannable. Every sentence provides actionable information—usage triggers, differentiation, combination chain, and pitfalls—with no fluff. It front-loads the login requirement and primary usage, then dives into specifics.

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 there is no output schema, the description compensates by explaining the nature of participation (array, multiple types), pagination behavior, and the distinction from list_my_signups. It covers login, defaults, and edge cases (window=all). An agent has all necessary information to invoke the tool correctly and interpret results. No gaps.

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

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

Although the schema covers 100% of parameters, the description enriches each: window is defined with clear meanings (upcoming=not ended, past=ended, all=default), cursor is tied to nextCursor from previous page, and limit has a max of 50. It also highlights the pitfall that participation is an array, which is output semantics but still helps parameter interpretation. This goes beyond the schema's simple descriptions.

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

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

The description clearly states the tool's function: answering '我参加过 / 即将参加的活动' (activities I participated in or will participate in). It specifies the four participation types (报名、现场签到、线上参会、当嘉宾) and explicitly differentiates from list_my_signups, which answers whether the organizer recorded the user. The verb 'list' and resource 'my activity history' are unambiguous and distinct from siblings like list_my_activities and list_my_invitations.

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 provides explicit when-to-use conditions: when the user asks about upcoming or past activities with specific examples. It also gives a clear when-not-to-use: when the question is about the organizer's recording status (list_my_signups). It names the alternative tool and even describes a combination chain with get_signup_activity for detailed info, and explains how to handle pagination for past data.

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