Server Quality Checklist

Tool Scores

• get_top10A
  3.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds '当前' and the list of returned fields, which is mildly useful, but it does not disclose additional behavioral details such as data freshness, pagination, or error conditions. With annotations present, this is adequate but not rich.

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

  Conciseness5/5

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

  A single sentence that front-loads the core purpose and then lists the returned fields. Every word earns its place; no fluff or irrelevant detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple, has two optional fully documented parameters, read-only/open-world annotations, and an output schema. The description is sufficient for an agent to invoke it correctly without missing critical context.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the input schema fully documents both 'limit' and 'preview_chars'. The description's mention of '预览' aligns with the preview_chars parameter but does not add significant meaning beyond the schema. Baseline 3 is appropriate.

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

  Purpose4/5

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

  The description uses a specific verb ('读取') and a specific resource ('当前十大'), and enumerates the returned fields (board, thread ID, author, time, preview, link). It clearly conveys what the tool returns, though it does not explicitly name sibling tools to differentiate itself, so it falls just short of a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase '当前十大' implies this tool is for retrieving the current top-10 list as opposed to searching or reading a specific thread/board. However, there is no explicit guidance about when to prefer this tool over siblings such as search_posts or get_index_status.

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

• get_boardA
  3.8/5.0
  Behavior4/5

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

  Annotations already mark the operation as read-only and open-world, and the description adds useful behavioral context: it uses a locally saved forum session and does not expose credentials to the agent. This is security-relevant information beyond what the schema or annotations provide, and it does not contradict readOnlyHint.

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

  Conciseness5/5

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

  The description is a single compact sentence, and each clause earns its place: the first states the action and scope, the second adds a credential-safety guarantee. There is no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a low-complexity read-only tool with an output schema and supporting annotations, the description covers the essential security and scope context: one page, local session, no credential exposure. Minor gaps like pagination limits or error behavior are acceptable given the schema and annotations.

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

  Parameters3/5

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

  Schema description coverage is 100%, so page and board are already documented in the input schema. The description's reference to '一页' loosely aligns with the page parameter but adds no additional format, constraints, or parameter-specific guidance beyond the schema.

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

  Purpose4/5

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

  The description states a specific action, '读取一页版面目录' (read one page of a board directory), which clearly identifies the resource and scope. It distinguishes the tool from siblings like get_thread or search_posts by focusing on '版面目录', though it does not explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended use is implied: use this tool when reading a single page of a board directory. However, the description provides no explicit when-to-use/when-not-to-use guidance and does not mention the sibling tools or criteria for choosing among them.

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

• search_postsA
  4/5.0
  Behavior4/5

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

  Annotations already indicate a read-only operation, and the description adds useful behavioral context: search operates on a local index, results are deduplicated to the most relevant hit per topic, and original post locations are returned. No contradiction with readOnlyHint or openWorldHint. It stops short of detailing ordering/pagination, but the annotation coverage lowers the bar.

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

  Conciseness5/5

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

  One compact sentence with the action front-loaded and the distinctive result behavior included. No filler or repetition of schema/annotation fields.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a search tool with a full input schema and an output schema, the description covers the essential behavior and result shape at a high level. Missing explicit sibling differentiation is already penalized in usage_guidelines; overall the definition is complete enough for an agent to select and invoke it correctly.

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

  Parameters3/5

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

  The input schema already documents all six parameters with 100% coverage, including defaults, formats, and examples. The description adds no parameter-specific meaning, so the baseline 3 applies; the schema carries the burden.

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

  Purpose5/5

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

  The description states a specific verb (检索), a specific resource (本地标题和正文索引), and a distinctive result behavior (one hit per topic plus original post location). This clearly differentiates it from sibling getters like get_thread and get_board, which retrieve rather than search.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this tool is for searching the local title/body index, so the intended context is recognizable. However, it never explicitly names alternatives or states when not to use it, leaving the agent to infer routing from the tool name and siblings.

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

• get_threadA
  4.2/5.0
  Behavior4/5

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

  注解已声明 readOnlyHint=true，描述也以“读取”明确这是只读操作，二者一致。描述额外补充了返回内容构成（正文、楼层、作者、附件），并隐含分页读取行为，增加了注解之外的可预期信息。

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

  Conciseness5/5

  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.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  对于 4 个参数、只读注解和输出 schema 已存在的工具，描述已覆盖核心调用条件和返回内容。虽然未提及错误场景或与兄弟工具的边界，但结合 schema 与注解已足够支撑正确调用。

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

  Parameters3/5

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

  输入 schema 的参数描述覆盖率为 100%，board、thread_id、page、max_chars_per_post 都已有说明。描述本身没有为参数提供超出 schema 的额外语义，因此按高覆盖率基准评为 3 分。

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

  Purpose5/5

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

  描述明确说明了操作对象（按版面名和主题 ID 读取主题页）和返回内容（正文、楼层、作者信息、附件链接），与 get_board、get_top10 等兄弟工具区分度高，代理无需打开 schema 即可理解工具用途。

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  描述给出了明确的使用条件：需要提供英文版面名和主题 ID，并可选页码。虽然没有显式说明何时不应使用本工具或推荐其他兄弟工具，但使用场景已经足够清晰。

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

• get_index_statusA
  4.5/5.0
  Behavior4/5

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

  The '查看' wording aligns with the readOnlyHint annotation, confirming a safe read operation. The description adds useful behavioral context beyond the annotation by disclosing that the index is local and that coverage limitations exist, which helps set expectations about data completeness.

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

  Conciseness5/5

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

  The description is a single well-structured sentence that front-loads the subject and lists the key output fields without redundancy. Every phrase adds value, and there is no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that there are no parameters, there is an output schema, and annotations already indicate read-only behavior, the description is complete for practical invocation. It enumerates the status dimensions an agent would need to expect from the tool.

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

  Parameters4/5

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

  This tool has zero parameters, so there is no parameter documentation burden. Per the baseline for zero-parameter tools, the description does not need to add parameter meaning; it is already fully sufficient in that regard.

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

  Purpose5/5

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

  The description states a specific verb ('查看' / view) and a distinct resource ('本地索引状态' / local index status), listing the exact status dimensions: boards, topics, content counts, date range, source, and coverage limits. This clearly separates it from sibling tools that fetch forum content or perform searches.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies a clear use case: call this tool when you need to inspect the local index's state and coverage. It does not explicitly name alternatives or state when not to use it, but for a zero-parameter status snapshot tool, the context is clear enough.

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