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

注释已提供readOnlyHint=true和destructiveHint=false，描述了安全轮廓。描述在此之上额外披露了行为：会自动补上skill_version与鉴权头，并把params平铺到body顶层。这些信息超出注释，有助于代理理解调用时的内部处理。没有矛盾，虽然未提及错误处理或返回格式，但输出模式已存在，此分数合理。

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?

描述分两段，第一句直接说明用途和适用条件，第二句解释自动行为和优先级建议。每个句子都有价值，无冗余，关键信息前置，结构清晰。

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?

该工具是一个通用网关调用，复杂度中等。描述已涵盖使用场景、行为细节（自动补头和扁平化）、参数说明（通过schema），并有输出模式存在。缺少的信息如返回格式由输出模式补充，代理可以正确调用，因此完整。

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覆盖率为100%，模式本身已包含两个参数的描述（api_name的示例和params的平铺说明）。描述文本没有添加超出schema的额外语义，仅重申了平铺行为，与schema描述一致。由于schema已充分说明，基线为3，描述未额外增值。

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?

描述明确说明这是一个直连网关的兜底工具，用于当某个接口没有对应专用工具时。动词'直连'和资源'网关'清晰，与兄弟工具（如get_book_info等专用工具）形成明确区分，指出它是备用选项而非首选。目的非常清晰且能区分于其他工具。

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?

描述明确给出了使用时机：'当某个接口还没有对应的专用工具时使用'，并明确指示'能用专用工具时优先用专用工具'，还说明专用工具的优点（字段口径与避坑规则）。这提供了明确的when和when-not，以及替代方案，没有任何推断空间。

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 existing readOnlyHint=true and destructiveHint=false annotations, the description adds valuable behavioral details: fixed 20-item response, no pagination, sorting by popularity, and the exact returned fields (`markText`, `items[].totalCount`). This materially helps an agent predict behavior and is 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?

The description is compact and front-loaded: the first sentence states the core purpose and fields, and the second explains critical server-side limits. The cross-reference to `get_highlight_reviews` adds useful integration guidance with no 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?

Given the rich annotations, full schema coverage, and presence of an output schema, this description is nearly complete. It adds the critical no-pagination and top-20 behavior plus a cross-tool usage hint. The only missing element is an explicit comparison with sibling highlight tools, which is a minor gap.

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?

All three parameters are already fully documented in the schema (100% coverage), so the baseline is appropriate. The description does not add meaningful input-parameter semantics beyond what the schema already provides; its `items[].range` mention concerns output, not parameters.

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 verb and resource: '获取书籍/章节的热门划线' with the endpoint `/book/bestbookmarks`, and clarifies it is sorted by popularity. However, it does not explicitly contrast itself with sibling tools like `get_book_highlights` or `get_chapter_underlines`, so differentiation is left mostly to the name and inferred meaning of '热门'.

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 operational context but no explicit when-to-use versus alternatives. It mentions that the server always returns the top 20 items, does not support pagination, and that `items[].range` can be passed to `get_highlight_reviews`; the choice of when to use this tool instead of a sibling is implied rather than stated.

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 and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context about the output: chapters[].level indicates hierarchy, price=0 is free, paid=1 is purchased, and chapterUid is a required input for three named sibling tools. This goes beyond annotations and enriches the agent's understanding of the return structure and downstream usage.

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 every sentence carries useful information, but the formatting with line breaks and backticks makes it slightly dense. It is still front-loaded with the core purpose, followed by field semantics and cross-tool usage, so it largely 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?

Given a single parameter, read-only annotations, an output schema, and a clear cross-tool dependency chain, the description is complete. It explains the meaning of key fields, how to interpret payment status, and why chapterUid matters, leaving no obvious gap for an agent to invoke 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?

The input schema has 100% coverage and describes book_id as '书籍 ID', so the description need not repeat it. The description does not add any extra meaning about the parameter itself, earning the baseline score of 3 for high schema coverage.

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 '获取书籍章节目录' (get book chapter table of contents), clearly identifying a specific verb and resource. It further specifies the intended use as a prerequisite for calling get_chapter_underlines, get_best_highlights, and get_highlight_reviews, distinguishing it from the listed sibling tools and giving an agent clear grounds for selection.

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 states when to use the tool: '需要按章节查划线时先用本工具取得' (when looking up underlines by chapter, first obtain chapterUid with this tool). This names dependent sibling tools and gives a concrete conditional, providing strong usage guidance beyond mere purpose.

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 bookmarks (type=0) are automatically filtered out, only highlights (type=1) are returned, and bookmark content is currently unavailable for export. This is material behavioral context an agent needs.

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: the core purpose appears first, followed by filtering behavior, formatting instructions, and sibling-tool coordination. Every sentence adds value without 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 read-only, single-parameter tool with an output schema, the description is complete: it explains what is filtered, how results should be grouped and formatted, the bookmark limitation, and the required pairing with get_my_reviews for full note export.

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 single parameter book_id is already fully documented in the schema with '书籍 ID' (100% schema coverage). The description only refers to '某本书' and adds no additional semantic detail, so the baseline score of 3 is appropriate.

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 '获取我在某本书里的划线内容' (get my highlights in a book), a specific verb+resource statement. It further clarifies that only highlights (type=1) are returned, not bookmarks, which distinguishes it from related note/review tools.

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 gives explicit when-to-use guidance: for '导出这本书的所有笔记', the tool must be combined with get_my_reviews. It also states bookmarks cannot be exported and their count is available via list_notebooks, providing clear exclusions and alternatives.

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 and destructiveHint=false, lowering the bar for safety disclosure. The description adds meaningful behavioral detail: the exact endpoint, the percent scale for newRating, how to render deepLink as a markdown link, and the fallback user message on failure.

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 well-structured: it opens with the core purpose, then covers response rendering, then failure behavior. Every sentence carries useful information, though the field list is slightly dense.

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 the presence of an output schema and read-only annotations, the description covers the essential behavioral extras: endpoint, display rule, and error fallback. The main gap is the lack of explicit sibling differentiation, but that is minor for such a simple read 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?

Schema coverage is 100% and the single parameter book_id is already described in the schema with its source ('来自 search_books 等接口的 bookId'). The description itself adds no parameter-level detail, so the baseline score of 3 is appropriate.

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 ('获取'), a clear resource ('/book/info'), and a precise scope: basic book information including title, author, translator, description, category, publisher, ISBN, word count, and rating scale. This is sufficient to distinguish get_book_info from sibling tools like get_book_chapters or get_book_highlights.

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 implies when to use the tool — when basic book details are needed — and the schema notes that book_id comes from search_books, which hints at a workflow. However, there is no explicit guidance about when not to use it or which sibling tool to prefer for alternative needs.

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 and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context beyond that: it specifies the output contains only counts/scores/position ranges and explicitly excludes underline text, which is a behavioral trait not captured by annotations. It doesn't mention pagination or rate limits, but given the annotation coverage and the tool's simplicity, this is a solid disclosure.

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 concise and well-structured. It uses a bullet point to separate the core purpose from the exclusion and the alternative. Every sentence earns its place: the endpoint, the output scope, the use case, and the sibling tool reference. No fluff or redundant phrasing.

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?

With an output schema present, the return values are already defined and need no explanation. The description covers the purpose, what the tool does and does not return, and when to use an alternative. It doesn't discuss edge cases like empty chapters or pagination, but for a simple read-only statistics tool, these are minor. The description is complete for an agent to decide whether to call this tool and what to expect.

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 all parameters (book_id, chapter_uid, synckey) are already documented in the input schema. The description doesn't add significant parameter-specific semantics beyond what the schema provides; it only ties the tool's purpose to the chapter parameter implicitly. The schema already includes helpful notes like '章节 UID，来自 get_book_chapters' for chapter_uid. Baseline 3 is appropriate since the schema carries 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 clearly states the tool's function: '获取某章节内每条划线的热度统计' (get heat statistics for each underline in a chapter), names the endpoint `/book/underlines`, and explicitly states what it returns (count/score/position range) and what it excludes (text). It also differentiates from the sibling `get_best_highlights` by noting the alternative for original text. This is specific and distinguishes it from siblings.

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 explicit usage guidance: it is for displaying the 'X people underlined' label ('用于展示「X人划线」标签') and directly tells the agent to use `get_best_highlights` when original text is needed ('需要划线原文请用 get_best_highlights'). This clearly defines when to use this tool versus the alternative.

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` and `destructiveHint=false`, so the safety profile is conveyed. The description adds value by explaining the request assembly (reviews array transformation), the response structure (abstract, content, author, createTime), and the pagination-related parameters (max_idx, synckey). No contradiction with annotations. It does not mention rate limits or error behaviors, but those are not mandated.

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 few sentences that front-load the core purpose, then add essential assembly and response details, and end with the sibling routing. It avoids fluff and remains readable, though it could be slightly more compact by merging some clauses.

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 the tool's moderate complexity (6 params, no nested objects) and the existence of an output schema that documents return structure, the description is complete. It covers the request construction, response fields, and provides an alternative tool pointer. Missing explicit error handling or edge cases, but these are not critical for correct 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%, with every parameter documented (ranges source and format, count limits, pagination fields). The tool description adds no extra parameter meaning beyond what the schema already provides. Baseline of 3 is appropriate because 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 (获取/fetch), a clear resource (指定划线范围下面的想法/评论), and the API endpoint (`/book/readreviews`). It explicitly contrasts with `get_review_detail` for single-review detail, and lists the response fields. This distinguishes it from sibling tools like `get_best_highlights` and `get_my_reviews`.

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 states a clear condition for using `get_review_detail` instead (when single-thought complete details including comments/likes are needed). It also implies `ranges` come from `get_best_highlights`. However, it does not explicitly exclude other sibling tools or explain when this tool is preferable over `get_my_reviews` or `list_book_reviews`, leaving some ambiguity.

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 this a read-only, non-destructive operation, and the description adds substantial behavioral detail beyond that: conditional fields (abstract/range only when locatable), star value semantics, chapterName being populated only for chapter comments, and pagination behavior via hasMore/synckey. No contradictions with 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 well-structured with a purpose sentence followed by precise bullet points. Every sentence adds needed information: endpoint, content scope, field conditions, star/chapterName semantics, pagination, and sibling relationship. It is compact given the complexity of the response semantics.

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 paginated tool that has an output schema, the description covers what an agent needs: what the tool returns, how conditional fields behave, pagination mechanics, and how it fits with get_book_highlights. The output schema and annotations handle the remaining structural detail.

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 value by explaining how synckey should be used for pagination (pass back the returned synckey when hasMore=1), which is not meaningfully captured by the schema alone. It does not overly repeat parameter 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 a specific verb and resource: getting personal thoughts and reviews within a book via /review/list/mine, and enumerates the included content types (划线想法, 章节点评, 整本书评). It also names get_book_highlights as the complement, helping differentiate it from the broader set of sibling tools.

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 by noting that pairing with get_book_highlights yields the complete single-book note content. However, it does not explicitly state when not to use this tool or which sibling alternatives (e.g., list_book_reviews, get_review_detail) should be chosen instead.

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 mark the tool as read-only and non-destructive, and the description adds substantial behavior beyond that: the internal sequence of API calls, the sort order by readUpdateTime, the ebook-only scope, and exact user-facing responses for empty-shelf and failure cases. This gives the agent a rich, accurate model of what happens when the tool is invoked.

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 well-structured: purpose first, then internal behavior, then scope constraints, then edge-case responses. Every sentence contributes operational knowledge, and there is no filler or repetition of annotation 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?

For a single-parameter orchestrating tool with an output schema, the description is complete: it explains what is aggregated, how the limit is used, which resources are excluded, and how failures/empty states are handled. The agent has everything needed to invoke it correctly and set expectations.

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 already describes recent_book_limit with a default and purpose, so the baseline is 3. The description adds meaningful context by explaining that this limit controls how many ebooks get progress queries, sorted by readUpdateTime, and that its default avoids excessive calls on large shelves—value beyond the schema text.

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 enumerates the exact components: shelf overview, recent N ebook progress, and notes overview. It also distinguishes itself from sibling per-resource tools like get_shelf, get_reading_progress, and list_notebooks by framing itself as the aggregate profile workflow.

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 clearly communicates that this tool is the one-shot 'profile.md' workflow for a complete reading overview, which implies it should be chosen over calling individual sibling tools separately. It also gives a scoping rule (only ebooks in books[], not albums), but it does not explicitly name alternatives or say when NOT to use it, so it falls 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?

注释已声明readOnlyHint=true，描述进一步补充了数据解释规则：progress为0-100整数百分比、finishTime条件、readingTime与recordReadingTime的区别、时间戳转换，以及_computed字段的预计算含义，这些远超注释提供的信息，且未与注释矛盾。

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?

描述采用分点结构，信息密集但每个要点都有价值（进度、时长、时间戳、计算字段），没有冗余。稍长但针对复杂语义是合理的。

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?

尽管存在输出schema，描述仍解释了关键字段的语义和转换规则，确保agent能正确解读数据。覆盖了所有可能误用的点（如百分比、时间单位），完整无缺。

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?

book_id在schema中已有描述（书籍ID），覆盖率为100%，描述未额外解释参数格式或用法，但基于schema已足够，基线3分。

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?

描述明确说明“获取某本书的阅读进度”，动词+资源清晰，且与兄弟工具（如get_read_stats、get_reading_overview）在语义上区分明显，因为它专注于单本书的进度细节。

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?

描述未提及何时使用该工具而非其他替代品，也未说明排除条件。虽然从名称和上下文中可推断用途，但没有显式指导，agent可能需要自行判断。

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 state readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds critical behavioral details: it warns that 'dayAverageReadTime' uses a natural-day denominator, not 'readDays', and that 'preferAuthor[].readTime' is a formatted string, not seconds. It also explains the time distribution order and the limitation on date ranges. These details go beyond the annotations and are essential for correct interpretation of results.

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 structured with clear headers (units, periods, computed, failure). It front-loads the most critical warnings about units and periods. Every sentence serves a purpose, either clarifying semantics, providing computation guidance, or specifying error handling. It is comprehensive yet organized, making it easy to scan.

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 the tool's complexity (multiple fields with non-obvious units, fixed-period limitations, and cross-period combination logic), the description is complete. It addresses all potential pitfalls, provides alternative strategies for periods not covered, and even gives guidance on failure responses. The output schema exists, so return values need not be described in detail, but the description covers semantics that the schema cannot convey.

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 provides comprehensive descriptions for both 'mode' and 'base_time', with enum values and default behavior. The description adds extra context about 'base_time' (normalization to period start) and emphasizes unit pitfalls that are not in the schema. Since schema coverage is 100%, the description's added value is moderate but significant for error prevention, warranting a score above baseline.

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 purpose with a specific verb ('获取' = get) and resource ('个人阅读统计' = personal reading stats), and identifies the endpoint. It distinguishes itself from sibling tools like 'get_reading_overview' or 'get_reading_progress' by focusing on statistical aggregates. The purpose is 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 explicit when-to-use and when-not-to-use guidance. It states that this tool only supports fixed natural periods and cannot accept arbitrary start/end dates, and it gives concrete alternatives for cross-period queries (using 'annually' for whole years, 'monthly' for months, and 'dailyReadTimes' for boundary adjustments). It also warns about units and provides failure response guidance, making usage conditions crystal 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the endpoint path and mentions that it returns content, author, comments, and likes, which provides some context. However, it doesn't disclose behavioral traits such as pagination behavior for comments/likes, how `synckey` affects the response, or whether the tool returns partial data if optional parameters are omitted. These are not critical but could be useful given the complexity of the parameters.

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 sentence that is efficient and front-loaded: it starts with the main purpose (获取单条想法的完整详情), includes the endpoint, and lists the key contents. No filler or redundant information. Every part 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?

The description is adequate for a read-only tool with a rich output schema. It states the purpose, and the output schema (though not shown in the context) likely details the return structure, so the description needn't explain return values. However, given the tool has 6 parameters and includes pagination controls (likes_direction, comments_direction), the description could have noted the sorting/pagination behavior to help agents set appropriate parameters. The annotations cover safety, so the main gap is a lack of guidance on parameter usage, but it's not critical for a simple fetch.

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 schema already documents all six parameters with descriptions. The description adds no parameter-specific information; it only mentions that it includes comments and likes, which maps to `comments_count` and `likes_count`. The baseline is 3 because the schema handles parameter semantics well, and the description doesn't need to compensate.

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 verb '获取' (get) and the resource '单条想法的完整详情' (single review's complete details), including the endpoint path `/review/single`. It lists the key contents (内容、作者、评论与点赞), which helps distinguish it from sibling tools like `get_my_reviews` that list multiple reviews. However, it doesn't explicitly mention that this is not the same as listing reviews, so it slightly lacks sibling differentiation beyond the singular vs plural framing.

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 implies usage when a single review's detail is needed, but it doesn't explicitly state when to use this tool versus the sibling tools like `get_my_reviews` or `get_best_highlights`. It provides no exclusions or conditions. The 'single' in the description and the fact that it requires a `review_id` hint at the use case, but that guidance is implicit rather than explicit.

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 mark the tool as read-only and non-destructive. The description adds useful behavior: the server has precomputed `_computed` fields, the counting formula is mandated, and a specific failure response is provided. This goes beyond the annotations without contradicting them.

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 longer than average, but every section earns its place: purpose, forced counting semantics, optimization guidance, and failure behavior. The bullet structure keeps it scannable, though it is slightly dense.

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 parameterless read-only tool with an output schema and safety annotations, the description is complete. It covers the endpoint, authentication model, exact counting semantics, recommends against inefficient sibling calls, and specifies the failure message.

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 coverage is 100%, so the baseline is 4. The description reinforces this by explicitly stating '无参数' and explains that authentication is handled via the API key, which is useful context.

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 gives the endpoint `/shelf/sync`. It clearly distinguishes this shelf-level operation from the sibling tools that retrieve individual books, highlights, or reading progress.

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 explicitly says the tool has no parameters and that identity comes from the API key. It also gives a direct usage rule: do not iterate `books` and call `get_book_info` to detect audiobooks; use `albums` instead. This is clear when-to-use and when-not-to guidance.

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 mark this as read-only, and the description adds substantial behavioral details: nested response structure, star-rating conversion, truncation of long reviews, date formatting, and the exact no-result message. This goes well beyond what annotations alone convey.

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 with the core purpose, followed by concise, useful behavioral notes. Every section adds distinct value, with no 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 read-only list tool with a fully documented schema and output schema present, the description covers the essential extras: response nesting, formatting transformations, truncation behavior, and fallback message. There are no meaningful gaps for an agent to call and interpret this 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 schema already documents all parameters including defaults, enums, and pagination semantics. The description adds no additional parameter-level meaning; it focuses on response behavior instead, which is fine but not above the baseline.

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 fetches public book reviews, explicitly distinguishes them from personal notes, and names the alternative get_my_reviews. The verb (获取) and resource (书籍公开点评) are specific and match the tool name.

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 says this is for other readers' reviews, not personal notes, and points to get_my_reviews as the correct alternative for personal notes. This gives the agent a clear when-to-use and when-not-to-use rule.

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?

注解已声明 readOnlyHint=true、openWorldHint=true、destructiveHint=false，描述没有与之矛盾。描述补充了“当前可用”这一动态性信息，并说明该工具是用于检查能力存在性和参数变化，但未进一步说明返回内容的结构特点或可能的体积问题。在注解已覆盖安全画像的情况下，这是可接受的中间水平。

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?

描述仅两句话，第一句直接说明工具行为和资源，第二句给出使用场景与排除场景，信息密度高、无冗余。内嵌的 JSON 示例虽简短但具有实际参考价值，整体结构清晰且关键信息前置。

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?

该工具无参数、有输出 schema、注解已覆盖只读与开放世界语义，描述又补充了使用时机和排除场景，代理无需额外推测即可正确调用。复杂度低，现有描述已构成完整调用上下文。

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?

该工具参数数量为 0，schema 覆盖率为 100%，参数语义主要由 schema 承担。描述中给出的 `{"api_name": "/_list"}` 作为调用示例增加了上下文，说明该工具本身如何触发清单返回，虽未涉及参数说明，但对零参数工具来说已足够。

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?

描述以明确动词“列出”指出资源是“微信读书网关当前可用的全部接口及参数定义”，并给出调用示例 `{"api_name": "/_list"}`，让代理能准确理解工具作用。与 call_gateway 等兄弟工具相比，它明显是“接口清单”而非具体业务查询，具有区分度。

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?

描述明确给出使用场景“用于排查某个能力是否还存在 / 参数是否变化”，并明确说明“日常问答不需要调用”，具备明确的 when 与 when-not 指引。但没有直接点名替代工具（如 call_gateway 或具体查询类工具），因此未达到最高分。

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 annotations (readOnlyHint, openWorldHint, destructiveHint), the description adds substantial behavioral detail: field semantics (noteCount is highlight count, total notes formula), pagination mechanics, and a note about a computed field. This fully informs the agent about how the tool behaves without contradicting 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 well-structured: it starts with the core purpose, then uses bullet points to explain field semantics, and ends with pagination details. Every sentence earns its place—there is no fluff. The front-loading of the main action and the logical grouping make it easy for an agent to parse quickly.

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 that an output schema exists, the description does not need to explain return values. It covers all tricky aspects: the distinction between noteCount and total notes, the pagination protocol, and the presence of a computed field. For a tool with two optional parameters, this is fully complete for correct 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?

The input schema already covers both parameters (count and last_sort) with descriptions, so schema coverage is 100%. However, the description adds critical usage semantics: how to use last_sort with hasMore, that count is the page size, and that offset/limit are unsupported. This goes beyond the schema, warranting a 4 rather than a baseline 3.

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 clear, specific action: '列出所有有笔记的书' (list all books with notes) and includes the endpoint. This distinguishes it from siblings like get_shelf or search_books, which have different scopes. The verb+resource is unambiguous and no tautology is present.

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 context on what the tool returns and how to paginate (cursor-only, no offset/limit), but it does not explicitly state when to use this over siblings like get_shelf or search_books. The purpose is self-evident, but there is no exclusionary guidance, so it stops 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?

Beyond the readOnlyHint and destructiveHint annotations, the description usefully discloses output fields (reason, newRating, readingCount), the pagination protocol (using the last item's searchIdx as the next max_idx), and the exact no-results response message. This gives the agent practical behavioral expectations not present in annotations alone.

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 concise and logically structured: purpose first, then output fields, then pagination, then empty-result message. Each segment earns its place, though the pagination detail partially duplicates the schema description.

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?

With an output schema present, the description doesn't need to enumerate return values in full. It still provides the key behaviorally relevant fields, the pagination mechanism, and the no-results phrasing, which is sufficient for an agent to invoke and interpret 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 coverage is 100% with both count and max_idx already described. The description's pagination line essentially restates the max_idx schema description ("上一页最后一条的 searchIdx") rather than adding new meaning, so it stays at the baseline 3.

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 identifies the tool as a personalized recommendation based on personal reading records and explicitly ties it to the App home page feature, giving a specific verb+resource. It does not explicitly name sibling tools, but the purpose is distinct enough from search_books and similar_books that an agent can differentiate it without opening schemas.

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 implies when to use the tool (when a personalized recommendation based on reading history is needed) by stating it matches the App home page recommendation. However, it does not explicitly say when not to use it or mention alternatives like search_books or similar_books, leaving the choice to inference.

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 and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the scope request/response mismatch warning, the pagination contract using searchIdx/max_idx, and the instruction not to claim total counts. It doesn't describe rate limits or auth, but for a read-only search tool the disclosed behaviors are 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 compact and front-loaded with the core purpose, then covers critical caveats. Every sentence earns its place: the scope warning, pagination rule, and empty-result phrasing are all necessary for correct invocation. It is slightly dense but well-organized with line breaks.

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 a rich output schema and full parameter documentation, the description covers the essential operational details: when to use it, how to paginate, how to interpret scope, and how to phrase results. The output schema handles return values, so nothing critical is missing.

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 schema already documents all four parameters. The description adds extra semantic value by explaining the scope mismatch trap and the pagination flow, which are not in the schema. It also clarifies that count should be omitted when the user doesn't specify a number. This goes beyond the baseline 3.

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: search the WeRead bookstore via `/store/search`. It also explicitly says to use this tool first to get a bookId when the user mentions a book title, which distinguishes it from sibling tools like get_book_info or recommend_books. The title is in Chinese but the description clarifies the exact endpoint and role.

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 explicit when-to-use guidance: '用户说书名时先用本工具拿 bookId，再调用其它工具' (when the user says a book title, first use this tool to get bookId, then call other tools). It also provides detailed pagination and response-handling rules, and even specifies what to say for empty results. This is far beyond a minimal usage note.

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 safe-read annotations, it discloses the underlying forwarded endpoint `/book/detailinfo?listtypes=2`, warns that `count`/`max_idx` must be explicitly passed or results may be abnormal, and documents the result location and pagination session mechanics. This is meaningful behavioral context not carried by annotations or schema alone.

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 tight sentences lead with purpose, then add a critical caveat, then explain result shape and pagination. There is no filler, and each clause 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?

Given annotations, an output schema, and four documented parameters, the description covers everything needed to call correctly: endpoint behavior, mandatory explicit arguments, result location, and the pagination protocol. No practical gap remains for an agent deciding to invoke this 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?

Schema description coverage is 100%, and the schema already explains the required explicit values for `count` and `max_idx`, the initial session behavior, and pagination offsets. The description mostly restates these parameter rules while adding the result-path detail, so it provides only modest additional meaning.

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 it returns similar-book recommendations based on a given book, matching the app detail page's '相似推荐' section, and even cites the endpoint `/book/similar`. It is specific enough to be identified from siblings, but it does not explicitly contrast itself with related recommendation tools.

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 conveys when to use the tool: whenever similar-book recommendations for a specific book are needed, with semantics aligned to the book detail page. It offers clear context and strong procedural guidance for first call vs pagination, but does not formally state when-not-to-use or name alternatives.

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