Server Quality Checklist

Tool Scores

• get_current_novelA
  3.8/5.0
  Behavior3/5

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

  No annotations provided. The description implies a read operation ('view'), but doesn't disclose if it requires authentication, returns metadata vs content, or if it fails without a selected novel.

  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?

  Single sentence, front-loaded with the action and object. No extraneous words.

  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?

  Given simplicity (no params, no output schema), the description is nearly complete. However, adding context about what 'current novel' means or how selection works would improve it.

  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?

  No parameters exist; the schema is empty. Baseline of 4 applies as per instructions, and the description adds no parameter info beyond what the schema provides.

  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 clearly states the verb '查看' (view) and resource '当前选中的小说' (currently selected novel), distinguishing it from siblings like 'list_novels' and 'switch_novel'.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus alternatives, such as setting a novel selection first with 'switch_novel'. The description lacks prerequisites or exclusion criteria.

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

• list_novelsA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It lists the output fields, which is the key behavioral aspect. However, it doesn't disclose if there's pagination, ordering, or performance implications. For a zero-parameter list tool, this is minimally adequate.

  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 concise sentence that front-loads the purpose and key output fields. No redundant information; every word earns its place.

  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?

  Given no parameters and no output schema, the description covers the main purpose and usage context. It could mention ordering or whether the list is complete, but for the stated use (selecting an operation target), it is sufficient.

  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?

  There are no parameters, so the input schema covers everything vacuously (100% coverage). The description doesn't need to add parameter semantics, and with zero params, baseline is 4.

  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 exactly what the tool does: list all novels under the current account with specific fields (book_id, title, word count, total reads, serialization status). It distinguishes from siblings by specifying its use for selecting an operation target when multiple novels exist.

  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 when to use it: when there are multiple novels and selection is needed. It could explicitly state when not to use or mention alternatives, but in context of siblings, it's clear enough.

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

• get_novel_statsA
  4.3/5.0
  Behavior4/5

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

  The description provides clear behavioral context: it returns book-level stats (read_count, word count, serialization status) and per-chapter details. It also explains the default book_id behavior. No annotations are present, so the description carries the full burden and does so adequately, though it could mention that the tool is read-only and non-destructive.

  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 consists of two concise sentences. The first states the tool's purpose and output, the second explains parameter defaults. There is no redundant or superfluous information.

  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 description covers the tool's purpose, output (book-level + chapter details), parameter defaults, and default behavior when book_id is omitted. Given that there is no output schema and no annotations, the description provides sufficient context for an agent to use the tool correctly.

  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?

  With 100% schema description coverage, baseline is 3. The description adds value by explaining that chapter_detail defaults to true and that book_id defaults to the currently selected novel, which is not inferable from the schema alone. It also provides context on the output fields, enhancing understanding.

  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 clearly states the verb '获取' (get) and the resource '小说阅读数据' (novel reading stats), and distinguishes the output into book-level overview and chapter details. This differentiates it from sibling tools like list_novels or list_chapters, which serve different purposes.

  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 when to use the tool (to get reading stats) and explains the default behavior when book_id is not provided. However, it does not mention when not to use it or suggest alternatives, such as using list_chapters for chapter-only info.

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

• publish_chapterA
  4.3/5.0
  Behavior3/5

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

  Without annotations, description covers the two workflows and scheduling, but lacks details on error handling, side effects, or permission requirements. Adequate but not fully transparent.

  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?

  Two dense sentences with no wasted words. Information is front-loaded and well-organized.

  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?

  Given 6 parameters, no output schema, and no annotations, description is quite complete covering two main workflows and scheduling. Does not mention return values but acceptable.

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

  Parameters5/5

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

  Schema coverage is 100% and description adds significant value by explaining interactions: title optional when using file+chapter_no, publish_time format and behavior. Enhances understanding beyond schema.

  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?

  Description clearly states the tool publishes or schedules a chapter to a novel. It distinguishes two usage modes (direct content vs file extraction) and differentiates from sibling tools like list_chapters.

  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?

  Explicitly explains when to use direct content vs file extraction, and mentions scheduling with publish_time. Could be more explicit about prerequisites like needing a current novel selected, but overall clear.

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

• list_chaptersA
  4.5/5.0
  Behavior4/5

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

  No annotations present, so description carries full burden. It discloses that chapters include statuses (scheduled/published). As a read operation, no destructive side effects are implied; it is transparent enough.

  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?

  Two concise sentences: first defines core function, second adds critical default behavior. No wasted words.

  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?

  Good for a simple list tool with one optional parameter. Could mention output format (e.g., list of chapters with fields), but the description of included statuses is adequate.

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

  Parameters5/5

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

  Adds significant meaning beyond schema: explains default behavior when book_id is omitted. Schema coverage is 100% and description complements it with usage context.

  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?

  Clearly states it lists chapters under each volume of a novel, including scheduled/published status. Distinguishes from siblings like list_novels (lists novels) and publish_chapter (publishes a chapter).

  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?

  Provides context that omitting book_id uses the currently selected novel, which guides when to use it. Does not explicitly exclude other uses or mention alternatives, but sibling context aids differentiation.

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

• switch_novelA
  4.5/5.0
  Behavior4/5

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

  No annotations provided, so the description bears the full burden. It discloses that the tool sets a default novel for subsequent operations. This covers the main behavioral trait, though it omits details like session scope or error handling. Adequate for a simple switch operation.

  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 sentence with parenthetical clarification. It is front-loaded with the action, efficient, and contains no wasted words. Perfect conciseness.

  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?

  Despite its simplicity, the description covers all essential aspects: purpose, parameter source, and effect on future operations. With no output schema and a single parameter, the description is fully complete for the tool's complexity.

  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?

  Schema coverage is 100% with description for book_id. The tool description adds value by suggesting to use list_novels to obtain the ID, which goes beyond the schema. This extra guidance merits a 4.

  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 clearly states the tool's action: 'switch the current novel to operate on'. It specifies the parameter (book_id) and the effect (subsequent operations default to this novel). This distinguishes it from siblings like list_novels or get_current_novel.

  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 advises to use list_novels to find the book_id and explains that the selection persists until switched again. It implies usage before publishing/querying, but does not explicitly list when not to use or alternatives. Slightly incomplete for a perfect score.

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