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

With annotations already covering the read-only, idempotent, non-destructive safety profile, the description still adds information the annotations cannot say: a per-call price (¥0.1/次), billing only on success, and automatic refund on failure or empty results. That pricing and billing-failure behavior is exactly the kind of behavior an agent needs to weigh before spending calls.

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?

Three sentences, each with a distinct job: what it does, when to use it and what to chain into, and cost and billing terms. It is short and dense, though an inaccurate wording (文章 versus 回答) takes up part of its brevity.

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 read-only search tool with no output schema, the description covers purpose, return shape at a high level, downstream chaining, and cost, which is enough to call it correctly. It stops short of explaining pagination behavior or result ordering and whether the search returns both answers and articles.

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%, with keyword, limit, offset, and _token all documented inline, so the schema already carries parameter meaning. The description only reinforces that keyword drives the search and says nothing about pagination via limit and offset or about the _token header fallback. Baseline 3 is appropriate when the schema does the heavy lifting.

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 states a specific verb and resource (按关键词搜索知乎文章) and names what it returns (回答列表 with content ID plus basic engagement metrics), which separates it from zhihu_hot_list or zhihu_post_detail. It falls short of a 5 because of an internal inconsistency: it promises to search 文章 but says it returns 回答, two different Zhihu content types, which leaves the agent slightly unsure about what it is querying.

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 names concrete scenarios (关键词监测、内容发现、构建候选集) and tells the agent what to do next, namely that returned IDs feed into the detail and comment endpoints. It does not explicitly exclude alternatives such as zhihu_hot_list for trending content, but the routing context is clear enough for an agent to decide.

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