Server Quality Checklist

Tool Scores

• check_availabilityA
  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 burden. It clarifies this is a read/status operation and implies it does NOT mutate state, which is helpful given no readOnlyHint annotation exists. However, it doesn't describe the output format or whether the tool errors on unknown ISBNs. For a simple read tool with a clearly implied non-destructive nature, this is acceptable though 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?

  The description is compact—two sentences total—with the purpose front-loaded in the first sentence and usage guidance in the second. Every sentence earns its place with zero filler or 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?

  The description is complete for a simple single-parameter read tool. It provides purpose, usage context, and preconditions. The presence of an output schema (presumably with availability counts) means return value explanation isn't necessary. Sibling context makes the differentiation clear. Only minor optional enrichment (e.g., whether 'available copies' includes held items) would push it higher.

  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 coverage is 100% for the single 'isbn' parameter, so the schema already documents it fully as 'The ISBN of the book to check.' The description reinforces that ISBN is a prerequisite ('already has an ISBN') but adds little beyond the schema. Baseline 3 is appropriate since the schema does the heavy lifting.

  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 a specific verb+resource ('Check how many copies... are available to borrow') and clearly identifies the scope (stock availability for a specific book). It distinguishes itself from siblings by focusing on availability checking versus borrowing (borrow_book) or searching (search_books).

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

  Usage Guidelines5/5

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

  Explicitly states when to use: 'when the user already has an ISBN and wants to know stock levels before attempting to borrow, or just want a quick status check.' This provides clear context and helps the agent distinguish from when to use borrow_book or search_books.

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

• borrow_bookA
  4.3/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 disclosure burden. It explicitly discloses the mutation (reduces availability count), the recording of history, and the error-handling behavior (returns string error rather than throwing exception, and instructs to check return value). This is strong disclosure given zero annotations.

  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?

  Description is appropriately sized - two paragraphs that front-load the core purpose, then add behavioral context. It's efficient and every sentence adds information. Slightly verbose with 'on behalf on' typo and could be tighter, but no wasted sentences.

  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?

  Output schema exists so return format needn't be explained. The description covers purpose, prerequisites, side effects, error handling, and distinguishing context. For a 2-param tool with full schema coverage, this is quite complete. Slightly less than perfect due to lack of alias/other ISBN format details.

  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 coverage is 100%, so the schema already documents both parameters adequately. The description adds the contextual meaning of ISBN and member_id (that they need to be known beforehand), but the schema descriptions are already clear. Baseline 3 is appropriate when schema fully documents parameters.

  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 it borrows a book for a library member, with specific verb+resource+action. It also notes it reduces availability count and records in member history, distinguishing this from siblings like return_book and check_availability.

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

  Usage Guidelines5/5

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

  Description explicitly states when to use this tool (when user wants to check out/borrow and you already know ISBN and member ID). It differentiates from alternatives by noting the prerequisite of knowing the ID/ISBN in advance, which is useful given sibling tools like search_books exist.

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

• return_bookA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden and does well: it states the side effect ('increases the book's available copy count by one'), records the return in member history, and discloses the error-handling behavior (errors returned as strings, never raised). This is rich behavioral disclosure for a mutation tool with zero annotation coverage.

  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 appropriately sized at two sentences, front-loading the core action and then adding behavioral details. Every sentence earns its place. A minor improvement could be trimming, but it's tight and readable.

  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?

  The description covers side effects, error handling, and usage context. Since an output schema exists, the description needn't explain return values. It's complete for a two-parameter mutation tool given full schema coverage, though it could optionally clarify what happens on successful return (the output schema covers this).

  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 both parameters (isbn, member_id) are already well documented in the schema itself. The description adds the error-returns-as-strings nuance and the 'M001' example format, providing marginal value beyond the schema but not requiring more given full schema coverage.

  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 a specific verb+resource ('Return a previously borrowed book') and clearly states the scope ('on behalf of a library member'). It distinguishes itself from siblings by being the check-in counterpart to borrow_book, and the borrowing context is clearly established.

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

  Usage Guidelines5/5

  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 the user wants to return / check in a book they have borrowed'), establishes clear context, and the sibling tools (borrow_book, search_books, check_availability) make the differentiation evident. It also clarifies behavior around required inputs.

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

• search_booksA
  4.7/5.0
  Behavior5/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 of behavioral disclosure. It discloses the return format (list of matching records with title, author, isbn, available_copies), the empty-result behavior (plain string message), and the match semantics (case-insensitive, partial). This is thorough for a read-only search tool.

  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?

  Three well-organized sentences, zero filler. Opening sentence states the core purpose, second sentence covers usage guidance, third sentence covers return behavior. Each line earns its place and front-loads the most important 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 tool has a single simple parameter, an output schema that documents the return structure, and the description covers behavioral details like empty results and matching rules. For a search tool of this complexity, the description is complete and there are no gaps.

  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 single 'query' parameter is already documented in the schema ('matched against each book's title and author fields'). The description adds marginal behavioral context (case-insensitive, partial) but doesn't add significant new semantic detail beyond what the schema covers.

  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?

  Clear specific verb+resource: 'Search the library catalog by title or author'. Clearly states case-insensitive and partial-match behavior, and specifically enumerates what fields are searched. Distinguishes itself from siblings (return_book, borrow_book, check_availability) by being the search/discovery tool.

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

  Usage Guidelines5/5

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

  Explicitly states when to use: 'whenever the user wants to find books, browse what's available on a topic, or look up a specific author/title but doesn't already know the ISBN.' The ISBN exclusion phrase clearly draws the boundary against catalog-lookup alternatives, which is helpful guidance.

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