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

The description discloses the return payload (logged_in and username), adding behavioral detail. The readOnlyHint annotation already covers safety, so the explanation of return values supplements it without contradiction.

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?

Single sentence with front-loaded verb and resource, zero filler. Every word adds meaning and the return values are mentioned compactly.

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 zero parameters, a read-only annotation, and the mention of return fields, the description fully covers the tool's needs. No output schema is present, but the description explicitly lists the expected return values.

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?

No parameters exist, so the baseline is 4. The description appropriately omits parameter details since there are none to document.

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?

Uses specific verb '检查当前知乎登录状态' (check current Zhihu login status) and explicitly mentions returns (logged_in and username). Clearly distinguishes from sibling zhihu_login, which presumably performs login.

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?

Provides clear context that this is a status-checking tool, implying it should be used to verify login before operations. No explicit alternatives or when-not-to-use guidance, but the purpose is self-evident and reading-oriented.

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

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

With only minimal annotations (readOnlyHint=false, destructiveHint=false), the description provides rich behavioral context: draft vs. publish, manual review requirement, plain-text line-break formatting, strict rate limits (≥60s interval, ≤3/hour), and overwrite-prevention refusal. This goes well beyond the annotations and helps the agent anticipate side effects and failures.

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 compact and front-loaded: it states the purpose first, then covers publishing semantics, formatting, rate limits, and refusal conditions in four dense sentences. Every sentence adds useful, non-redundant information.

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?

Despite having no output schema, the description fully specifies the tool's behavior for selection and invocation: what it writes, how publishing works, formatting rules, rate limits, and refusal conditions. No important behavioral aspect is left ambiguous.

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?

The input schema already documents all three parameters with descriptions, so the baseline is 3. The description reinforces the text format and publish default but does not add substantial parameter-level meaning beyond what the schema already provides.

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 begins with a specific verb and resource: '把纯文本写入指定知乎问题的回答编辑器' (write plain text into the answer editor of a specified Zhihu question). It clearly distinguishes itself from sibling tools like zhihu_edit_answer by emphasizing draft-by-default behavior and refusing if an answer already exists.

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 clearly explains the default draft-only behavior, the publish=true option, and the refusal when an existing draft or answer is present, effectively implying use for new drafts. However, it does not explicitly name zhihu_edit_answer as the alternative for editing existing answers, so it falls just short of a 5.

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

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

Even though annotations already mark the tool as destructive (destructiveHint=true), the description adds substantial behavioral detail: it modifies live public content, requires a two-step confirm (preview with confirm=false, commit with confirm=true), preserves original content in append mode, and warns that replace mode loses images and rich-text formatting. It also mentions automatic local backup before modification, going far beyond the annotation flags.

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 a single dense paragraph but every sentence serves a purpose: purpose, confirmation flow, mode semantics, data-loss warning, backup, and permission constraint. It is longer than minimal but justified for a destructive editing tool with multiple modes. The structure could be improved with bullet points, but it remains efficient and front-loaded.

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 complex destructive tool with no output schema, the description covers the workflow, mode differences, data-loss risks, backup, and permission requirements. It does not describe the success response after confirm=true or error scenarios (e.g., authentication failure), but the sibling login tools provide context and the parameters are fully documented. Overall, the description is nearly complete for safe invocation.

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 100%, so the input schema already fully documents all four parameters. The description reinforces parameter behavior (e.g., confirm=false previews, text varies by mode), but adds little meaning beyond what the schema already provides, such as the plain-text caveat already present in the text parameter description. Baseline 3 is appropriate when the schema carries the semantic load.

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 opens with a specific verb and resource: '编辑你【已发布】的知乎回答' (edit your published Zhihu answer), clearly distinguishing this from sibling tools like draft_answer (for unpublished drafts) and get_content (for reading). It further clarifies the two modes (append/replace), making the tool's purpose unambiguous.

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 clear when-to-use context: editing one's own published answers, with a two-step confirmation workflow. It explicitly states a constraint, '只能编辑本人发布的回答' (can only edit answers published by yourself), but it does not name alternative tools or explicitly state when not to use this tool in favor of others, so it stops short of full alternative differentiation.

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

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

Annotations already declare readOnlyHint=true. The description adds valuable context about supported URL formats and the specific metadata returned (author, publish time, likes, comment count), going beyond 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?

Two tightly written sentences: the first states the core function, the second details supported URL formats and redirects comment-related queries to another tool. No wasted words.

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 a single parameter, a read-only annotation, and support for multiple URL types, the description sufficiently covers the tool's scope and return expectations. Minor omissions like pagination or size limits are not critical for a simple retrieval tool.

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?

The schema covering 100% of parameters already describes the 'url' parameter as a link. The tool description enriches this by listing the exact URL patterns accepted, providing meaning beyond the schema's minimal description.

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 reads content and metadata from Zhihu pins, column articles, and answers. It lists specific URL patterns, distinguishing it from sibling tools like zhihu_list_comments.

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 explicitly directs users to use zhihu_list_comments for comments, providing a clear alternative. It defines the supported URL types, making it clear when to use this tool, though it doesn't discuss other potential alternatives or exclusions.

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

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

The annotation readOnlyHint=true already discloses the safe read-only nature. The description adds meaningful behavioral context beyond that: how pagination works (cursor, next_cursor, has_more), and that only top-level comments are returned. It does not mention auth needs or rate limits, but the annotation lowers this burden.

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 exceptionally concise: two sentences, front-loaded with the main action, and every sentence carries necessary information. No filler or redundant restatement of the tool name.

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 3-parameter read-only tool with no output schema, the description adequately covers the key usage complexity: pagination protocol, stopping condition, and the distinction between first-level and nested comments. It could have briefly described the overall response shape, but it does mention next_cursor and has_more, which covers the essential return guidance.

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 descriptions for all parameters, so baseline is 3. The description adds value by explaining the cursor relationship (return next_cursor from previous page) and the '首页不传 cursor' rule, which is not fully obvious from the schema alone. The limit and url semantics are already in the schema.

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 a specific action ('分页读取' - paginated read) on a specific resource ('知乎想法或专栏文章的一级评论' - first-level comments on Zhihu ideas or column articles). It also distinguishes itself from the sibling tool 'zhihu_list_replies' by explicitly noting that nested replies belong to that tool.

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 when-to-use guidance is provided: use for first-level comments, and use zhihu_list_replies for '楼中楼回复' (nested replies). Pagination usage is clearly specified with instructions about cursor: '首页不传 cursor；用返回的 next_cursor 取下一页，has_more=false 表示读完.'

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

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

The annotations already declare readOnlyHint=true, so the safety profile is known. The description goes beyond this by disclosing the pagination contract: omit cursor on first page, use returned next_cursor for subsequent pages, and stop when has_more=false. This is valuable behavioral information not present in 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?

The description is two concise sentences, front-loaded with the core purpose, and reads naturally. Every sentence adds meaningful usage information without redundancy.

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 paginated read tool with no output schema, the description covers the essential operation: resource, default subject, and pagination protocol. It does not describe the return item structure, but '关注的人列表' makes the response type self-evident. The behavior is fully specified for practical use.

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%, so the baseline is 3. The description adds a bit of context by explaining the cursor flow and the default for url_token, but these details largely mirror the schema descriptions. It does not add substantial new parameter semantics beyond what the schema already provides.

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 uses a specific verb+resource: '分页读取某用户「关注的人」列表' (paged read of a user's followees list). It clearly identifies the operation and the target resource, and it is distinguishable from siblings like zhihu_list_user_activity and zhihu_list_comments.

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 gives clear usage context: how to query the current user vs. a specific user via url_token, and how to handle pagination with cursor and has_more. It does not mention sibling alternatives or exclusions, but this is a simple list tool where the primary usage pattern is well explained.

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

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

The readOnlyHint annotation already conveys safety. The description adds concrete pagination behavior (first page no cursor, use next_cursor later) and explains the provenance of comment_id, which goes beyond structured 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?

Two compact sentences fully convey the operation, pagination flow, and parameter provenance without repetition or filler.

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 simple read-only paginated list tool, the description covers the workflow adequately. It lacks details about response contents or auth requirements, but the pagination instructions and schema fill most 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?

Schema coverage is 100%, so parameters are already well-documented. The description adds extra semantic value by specifying that comment_id comes from zhihu_list_comments, which helps the agent source the correct value.

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 explicitly states the tool reads paginated nested replies for a given first-level comment (分页读取某条一级评论的楼中楼回复). It clearly distinguishes from sibling tool zhihu_list_comments by targeting replies to a comment rather than top-level comments.

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 provides clear usage context: comment_id comes from zhihu_list_comments and cursor handling for pagination. It doesn't explicitly exclude alternatives, but the relationship to the sibling list tool makes the use case evident.

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

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

Beyond the readOnlyHint annotation, the description discloses behavioral details: content is pulled in descending publish time and stops when items are earlier than the target day, and it explicitly excludes full content and comments. It also mentions the default timezone (Asia/Shanghai), adding valuable context beyond what annotations provide.

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 three sentences, each with a clear purpose: the first explains purpose and output, the second provides cross-tool usage guidance, and the third covers ordering/stop behavior and url_token. Every sentence earns its place with no wasted words.

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 and 5 parameters (all fully described in the schema), the description covers the essential workflow: what is listed, what is excluded, how to use related tools, and the pagination logic. It is self-sufficient for selecting and invoking the tool correctly.

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 100%, so the baseline is 3. The description adds minor clarity by restating the date default (Asia/Shanghai) and the url_token definition (after /people/), but these are already present in the schema, so no significant extra semantics are provided.

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 uses a specific verb '发现' (discover/list) with a clear resource: a user's answers/articles/pins on a specified natural day. It explicitly states what is returned and what is excluded, and distinguishes itself from sibling tools by directing to zhihu_get_content for full content and zhihu_list_comments for hot comments.

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 explicitly instructs to use zhihu_get_content for reading the full content and zhihu_list_comments for hot comments after obtaining the list, clearly indicating when not to use this tool. It also clarifies that this tool only returns list metadata, not full text or comments.

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

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

With no annotations, the description carries the full burden. It discloses that login state is stored locally, not returned via MCP, and that graphical interface is required. It also mentions a workaround for short timeouts. It could add behavior on successful/failed scans, but the disclosed information is substantial.

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 two sentences plus a note, front-loaded with the main action. Every sentence adds operational value, making it efficient and well-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 zero-parameter, no-output tool, the description covers prerequisites, side effects, and a fallback option. It lacks explicit success/failure behavior but is otherwise adequate for an AI agent to select and invoke the tool.

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?

The tool has zero parameters, and the schema covers 100% (vacuously). The baseline score of 4 applies, and the description adds context about what the tool returns (nothing), which is helpful.

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: opening a browser window for QR-code login to Zhihu. It uses specific verbs and resources, and the context about local storage distinguishes it from related tools like zhihu_check_login.

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 provides clear operational context: requires a GUI and warns about timeout issues, suggesting a terminal alternative (`npm run login`). It does not explicitly contrast with sibling tools like zhihu_check_login, but the usage context is clear.

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

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

Beyond the readOnlyHint annotation, the description discloses that search is fuzzy and may mix dates, that results are sorted by answer count, that visits_count serves as a heat proxy, and that it outputs specific candidates. These details help set expectations about behavior and output.

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 compact yet information-dense: it covers purpose, output structure, two convenience fields, fuzzy matching behavior, and the recommended workflow in just a few sentences. Every sentence earns its place.

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 search tool with no output schema, the description fully specifies the return list fields and the two candidate objects. It also explains the sorting order and the purpose of each key field, making it self-sufficient for an agent to invoke correctly.

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?

The description explains that the keyword is a fuzzy search query, that the date parameter filters titles to the exact day, and that limit controls the result count. It adds real-world context (like the example keyword) beyond the schema 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 searches Zhihu questions by keyword, returns a list sorted by answer count, and identifies two key candidates (most_answers and hottest). It also gives a concrete example query, distinguishing it from sibling tools like content retrieval.

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 provides explicit guidance: use this tool to locate the day's 'today's market' question, then pass its URL to zhihu_draft_answer. It also warns about fuzzy matching and advises passing a date to filter precisely, giving clear context for when and how to use it.

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