Server Quality Checklist

Tool Scores

• list_directorsB
  3/5.0
  Behavior2/5

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

  With no annotations, the description must fully disclose behavior. It mentions filtering and implies read-only browsing, but omits pagination, max_results limits, ordering, and return fields. This is insufficient for a zero-annotation 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?

  The description is two concise sentences with no filler. It front-loads the primary purpose and immediately indicates the filtering dimensions.

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

  Completeness2/5

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

  Given the simple parameter structure and absence of annotations and output schema, the description should explain more. It does not mention output format, pagination, or enum meanings, leaving users underinformed.

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

  Parameters2/5

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

  The description explains that genre and region are filters, adding meaning to two of three parameters. However, it does not clarify the semantic meaning of enum values (e.g., 'mv', 'k-pop') and completely omits max_results. With 0% schema coverage, this leaves significant gaps.

  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 clearly identifies the tool as a browse/list operation for the director reference library, with filtering by region or genre. It distinguishes itself from sibling tools by focusing on directors and implies a list action, though 'browse' is slightly less specific than 'list'.

  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 for browsing directors but provides no explicit guidance on when to use this tool versus alternatives such as get_director for individual details. No exclusions or decision criteria are given.

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

• list_photographersB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the library size and the available filter dimensions, but it does not describe the return shape, how max_results affects output, or what happens when no filters are supplied. It also does not explicitly confirm this is a read-only 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 that front-loads the resource and action, with no redundant words. Every phrase adds useful context, making it compact and easy to parse.

  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?

  For a relatively simple list tool with three optional parameters and no output schema, the description is adequate but leaves gaps. It does not mention max_results, does not specify what fields are returned, and the 'country' versus 'region' mismatch is a minor inconsistency. These omissions make it functional but not fully complete.

  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 schema covers only 33% of parameters with descriptions (only cluster has an explicit description). The description adds a helpful gloss for cluster ('lighting style group') and mentions 'country' as a filter concept, which loosely maps to the region enum. However, it does not explain max_results or the exact enum values for region, so it only partially compensates for the low schema coverage.

  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 the verb 'browse' and names a specific resource ('photographer style reference library'), and lists filtering dimensions. This distinguishes it from sibling tools like get_photographer or list_directors. However, it mentions 'country' as a filter, which is not a named parameter in the schema, creating slight ambiguity.

  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?

  There is no explicit guidance on when to use this tool versus alternatives like search_equipment or get_photographer. The description implies a read-only browsing use case, but it does not state exclusions, prerequisites, or reference any sibling tools.

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

• search_studiosA
  4/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 discloses that it returns specific data (rates, key features) and that it's free, but doesn't mention pagination, sorting, filtering logic, or read-only nature. The 'Search' implies read-only, but more explicit disclosure would be helpful.

  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 and front-loaded with the core purpose. Each sentence adds value: the first defines the resource, the second explains the return content, the third notes cost. 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?

  For a search tool with 5 optional parameters and good schema coverage, the description provides sufficient context about what results include and the free access. It lacks guidance on default behavior (e.g., max_results default) but that's in the schema. Overall complete enough for a filtered search.

  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 80% (4 of 5 params have descriptions). The description adds no extra parameter detail beyond what the schema already provides, and doesn't clarify relationships like AND/OR logic. Baseline 3 is appropriate since the schema handles most parameter semantics.

  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 ('Search') and the specific resource ('CrewOne database of Taiwan studios'), making it distinct from sibling tools like search_equipment or list_photographers. Additional context (561 studios, rates, features) further clarifies scope.

  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?

  While it doesn't explicitly name alternatives or exclusions, it clearly implies when to use: when searching for studios in Taiwan with specific criteria. The mention of 'Free to use' and returns of rates/features provides practical usage context.

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

• get_photographerA
  4.2/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 of behavioral disclosure. It reveals what the tool returns (hallmarks, lighting/palette/composition, prompt tokens, representative works) and implies a read-only lookup. It doesn't mention behavior for unmatched names or partial matches, but for a simple lookup this is reasonable coverage.

  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 two sentences: the first states the function and outputs, the second gives usage context and examples. Every word contributes value, with no repetition 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 single-parameter lookup tool with no annotations and no output schema, the description covers purpose, usage, and return contents, which is largely complete. However, it does not describe behavior for invalid or missing photographer names, which is a minor gap for a complete mental model.

  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 covers the single parameter fully (name with detailed description and examples), so schema coverage is 100%. The description adds contextual examples but no additional semantic information beyond what the schema already provides, earning the baseline score of 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?

  The description uses a specific verb and resource ('Look up a single photographer in the CrewOne 69-photographer style reference library') and enumerates concrete outputs (hallmarks, AI prompt tokens, representative works). This clearly distinguishes it from sibling tools like list_photographers or search_equipment.

  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?

  It explicitly states when to use the tool ('Use this when a user asks for a specific photographer style') with concrete examples. It does not mention when not to use it or explicitly name alternatives like list_photographers, so it falls just short of fully explicit guidance.

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

• search_equipmentA
  4.2/5.0
  Behavior4/5

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

  No annotations exist, so the description carries the full burden. It discloses the key behavioral aspects: it returns matching items with day rates, is free, and requires no API key. It does not explain ordering, pagination, or result limits, but for a simple read-only search, the essential behavior is covered.

  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 sentences, with the main action and resource front-loaded. Every sentence adds relevant information (scope, return value, access), with no 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?

  For a search tool with one required parameter and no output schema, the description explains what is searched and what is returned, and mentions access requirements. It does not describe the output format or any sorting options, but these are not critical for a basic search tool and are partly inferable from the schema and tool name.

  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 schema already provides descriptions for query and category, covering 67% of parameters. The description adds context about the database size and categories, but it does not add meaningful detail about max_results beyond its obvious default. This is acceptable given moderate schema coverage, so a baseline of 3 is appropriate.

  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 a specific verb ('Search') and resource ('CrewOne database of Taipei film equipment rental rates'), and further specifies the scope (1,187 SKUs, categories, day rates in TWD). This makes it unmistakable and distinguishes it from the sibling tools, which cover studios, photographers, and directors.

  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 implicitly guides use by identifying the exact domain (equipment rental) and the return value (day rates), which differentiates it from siblings. It also states 'Free to use; no API key required,' providing access prerequisites. However, it does not explicitly mention when not to use this tool or name alternatives, 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.

• get_directorA
  4.3/5.0
  Behavior4/5

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

  The description discloses key behavioral output (AI prompt tokens, representative works, signature techniques) and the 'look up' verb indicates a non-destructive read. However, it does not explicitly state side-effect freeness, auth requirements, or rate limits, which is a minor gap for a lookup 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?

  The description is two sentences, front-loaded with the main purpose, and efficiently includes necessary return details without any waste. Each sentence earns its place.

  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 (one param, no output schema, no annotations), the description is complete. It explains the lookup scope, the source library, and the exact return values, covering all essential context for an agent.

  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 fully describes the single parameter 'name' as 'Director name in English or Traditional Chinese' (100% coverage). The description does not add any additional meaning beyond referencing the library scope, so the baseline of 3 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?

  The description uses a specific verb ('look up') and resource ('single director... reference library'), clearly distinguishing it from siblings like list_directors and get_photographer. It also specifies the two included collections, adding precision.

  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 clearly implies when to use this tool (when needing a single director's details), but it does not explicitly mention alternatives or exclusions. Sibling tools like list_directors are not named, so guidance is clear but not fully explicit.

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