Server Quality Checklist

Tool Scores

• get_chapterA
  3.7/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 full behavioral burden. It mentions pagination via offset/nextOffset, which is useful, but does not disclose behavior when both number and title are provided, or when neither is provided. It also lacks details on error handling or text formatting.

  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 sentences, front-loaded with the core purpose, and immediately followed by the pagination detail. No wasted words; every phrase adds value.

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

  Completeness3/5

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

  Despite having no output schema and no annotations, the description covers the basic retrieval functionality and pagination. However, it lacks information on required parameters (none required, but likely number or title should be supplied), conflict resolution when both are given, and case sensitivity of title matching. This leaves room for ambiguity.

  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 provides clear descriptions for all 3 parameters (100% coverage). The description adds minimal value beyond the schema: it confirms the range for number and that offset is used for pagination. This is adequate but does not significantly augment the 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?

  The description clearly states the tool returns a chapter's verbatim text, specifying the two identification methods (number or title substring). It effectively distinguishes from sibling tools like list_chapters, which lists chapters, and search_content, which searches across content.

  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 usage via number or title but does not explicitly say when to prefer this tool over siblings, nor does it mention when not to use it. For example, it doesn't clarify that get_chapter is for retrieving full text while list_chapters is for listing titles.

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

• get_book_infoA
  3.9/5.0
  Behavior3/5

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

  Description lists returned content but does not disclose behavioral traits like read-only or side effects; no annotations to supplement.

  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 key info, no wasted words.

  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?

  For a param-less tool returning fixed book info, the description fully covers the output contents.

  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?

  No parameters exist, schema coverage is 100%, so description adds no param info; baseline score applies.

  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 returns title, author, license, etc. for a specific book, distinguishing it from siblings that cover chapters, designs, principles, etc.

  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?

  Usage is implied as retrieving book info, but no explicit when-to-use or alternatives among siblings are mentioned.

  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.0
  Behavior3/5

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

  The description provides the fixed number of chapters (17) and notes the output fields (numbers and titles), which adds transparency beyond no annotations. However, it does not disclose ordering, performance, or read-only behavior.

  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, front-loaded sentence that conveys all necessary information without waste. Every sentence 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 output schema, the description adequately explains what is returned. It lacks details like ordering, but for a fixed list of 17 items, it is reasonably complete.

  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?

  Since there are no parameters and schema coverage is 100%, the description adds value by specifying the output format (numbers and titles). Baseline with 0 params is 4, and the description meets this.

  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 action ('list all 17 chapters') and the specific resource ('chapters'). It distinguishes from siblings like 'get_chapter' by implying a full listing versus a single retrieval.

  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 does not explicitly state when to use this tool versus alternatives. However, the sibling tool names imply that this is for a complete list, while 'get_chapter' is for a specific chapter. No explicit guidance on context or exclusions.

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

• search_contentA
  4/5.0
  Behavior3/5

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

  No annotations present, so description bears full burden. It discloses that it returns 'most relevant verbatim paragraphs with their chapter', but does not explain relevance ranking, case sensitivity, or supported operators. It is adequate but not thorough.

  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 sentences: first covers purpose and output, second gives a usage hint. No unnecessary words. Highly efficient.

  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 simple search tool with no output schema, the description adequately explains return values (verbatim paragraphs and chapter). It could mention result limits or sorting, but the mention of 'most relevant' covers ranking. Minor gaps in full transparency.

  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% for both parameters 'query' and 'limit', so the description adds marginal value. It contextualizes the result as 'most relevant verbatim paragraphs', which enhances understanding beyond schema descriptions.

  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 uses specific verb 'search' and resource 'full book text', and specifies the output 'most relevant verbatim paragraphs with their chapter'. It also provides an example use case, clearly distinguishing it from sibling tools like get_chapter or 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?

  The description explicitly states when to use: 'Use for what does Bouricius say about X questions.' It does not mention when not to use or alternatives, but the sibling tools context and the clear purpose provide implicit guidance. Still, explicit exclusion could improve.

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

• get_multi_body_designA
  4.1/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden. It discloses that it returns verbatim excerpts from the book, which is transparent about content. However, it does not mention any safety or side effects, though none are expected for a simple read tool.

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

  Conciseness4/5

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

  The description is a single sentence that efficiently conveys the tool's purpose and enumerates the bodies. It is front-loaded with the core concept. Could be slightly more concise but carries necessary detail.

  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 is complete enough. It tells exactly what is returned (the design with excerpts). No additional context seems necessary for this simple 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?

  There are zero parameters, so per the baseline rule, the score is 4. The description adds no param-specific meaning because none exist, and schema coverage is trivially 100%.

  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 that the tool returns Bouricius's specific 'multi-body sortition' reference design from Chapter 16, listing all seven specialized bodies. This precisely distinguishes it from siblings like get_chapter (which returns chapter content broadly) or get_principles.

  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 the tool is used to retrieve that specific design, but does not explicitly state when to use it versus alternatives, nor provides any conditions or exclusions. Usage is implied but not explicitly guided.

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

• get_principlesA
  4.5/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries full behavioral burden. It discloses that the tool returns a verbatim excerpt and chapter, not a summary, which is transparent about the output format. However, it does not mention any potential limitations such as number of entries or pagination, but given the lack of parameters, this is minor.

  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 extremely concise with two sentences. The first sentence states the purpose and scope, the second adds specific details about output format and suggests alternative tools. Every word earns its place without redundancy.

  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 the tool's simplicity (no parameters, no output schema, no annotations), the description is fully complete. It explains what the tool does, what it returns, and how it relates to sibling tools, requiring no additional context for correct selection and invocation.

  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?

  The tool has no parameters, so the input schema provides no information beyond type object with no properties. The description adds no parameter-specific meaning, but according to the rule for 0 parameters, baseline is 4. The description compensates by explaining the output instead.

  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 'returns' and the resource 'key topics/arguments in the book' with a specific scope 'curated entry points'. It further distinguishes from siblings by noting that it provides verbatim excerpts with chapter references, not summaries, and directs to get_chapter or search_content for further reading.

  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 explicitly advises using get_chapter or search_content to read further, providing clear guidance on when to choose alternatives. While it does not explicitly state when not to use this tool, the context is clear that this is for curated entry points and not for full text.

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