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 幂等 restatement earns no extra credit. Beyond them it discloses real behaviors: login is required, no notification is emitted to the product owner, no friend/connection relationship is created, only published products can be followed, and a 404 is terminal. It stops short of saying what the call returns or what other error codes imply.

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?

Highly compact, front-loaded with the core action and side-effect profile, then the routing alternatives. The telegraphic semicolon style is efficient but borders on cryptic (e.g. 404勿重试 without stating what to do on other failures), so it is dense rather than perfectly structured.

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 write with full schema coverage and no output schema, the definition covers auth, side effects, error handling, and every plausible alternative tool. The remaining gap is that it never indicates what the agent observes after a successful follow (e.g. whether follow state is echoed), though get_my_card partially compensates.

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 productId description already tells the agent to source the cuid from get_product / search_products, so the schema carries the parameter burden. The only added meaning is the implicit constraint that the product must be published for the call to succeed, which is modest value on top of a fully documented single parameter.

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 (关注已发布产品 / follow a published product) and immediately distinguishes it from the two nearest alternatives, follow_creator (交友) and the read path get_my_card (关注列表). An agent can classify this against unfollow_product and follow_creator 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?

Explicit decision routing: use get_product then follow for products, use get_creator then start_conversation to contact the host, use follow_creator when the goal is social/friend-making, and check get_my_card to see existing follows. It even names the error condition (404勿重试) where the correct behavior is to stop rather than retry.

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