Server Quality Checklist

Tool Scores

• search_topicA
  3.5/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden for behavioral disclosure. It only says 'returns list of UIDs with metadata' and gives no information on search scope, pagination, sorting, permissions, or side effects. This is a significant gap for a tool that likely is read-only but is not explicitly stated.

  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 one sentence that is direct and front-loaded with the key action ('Tìm kiếm') and outcome. Every word contributes to the meaning, and no unnecessary detail is included.

  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?

  The description covers the basic purpose and output, and the schema fully documents parameters, so it is minimally complete. However, there is no output schema and the description leaves 'metadata' undefined, plus no mention of search behavior or limits, making it incomplete for a full understanding.

  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%, and the description does not add meaningful detail beyond the schema. Both 'topic' and 'language' are already described in the input schema, so the 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 the tool searches for suttas related to a Buddhist topic and returns UID list with metadata. This specific verb-resource-output combination distinguishes it from sibling tools like get_sutta or get_parallels.

  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 when needing to find suttas by topic, but it does not explicitly state when to prefer this over siblings or any exclusions. No alternatives are mentioned, so guidance is only implied.

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

• get_suttaA
  3.7/5.0
  Behavior2/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 only states the action (get full text) and does not reveal side effects, return format, or any caveats like segment limits or read-only nature beyond what the schema already indicates.

  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 short sentences, front-loaded with the main action, with no unnecessary words. It is exemplary in conciseness.

  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?

  Though the tool is simple and the schema is rich, the absence of annotations and output schema means the description should have elaborated on the response structure or limiting behavior. It is adequate but minimal.

  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 baseline is 3. The description adds no additional parameter semantics beyond reiterating that UID is the key; all useful parameter details (e.g., examples, defaults) are already present in 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 retrieves the full text of a sutta by UID, using a specific verb and resource ('Lấy toàn văn một sutta theo UID'). It distinguishes from siblings by emphasizing it operates on a known UID and pairs with search_topic.

  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 says to use this tool after finding the UID via search_topic or when it is already known, providing clear contextual guidance. It does not enumerate when-not scenarios, but the primary usage context is well-established.

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

• get_parallelsA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It implies a read-only operation ('get list') and adds helpful context about what parallels are, but it does not disclose any other behavioral traits such as return format, pagination, or potential variations in data sources.

  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 one concise sentence that explains both the action and the domain concept. No filler words; every part 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?

  The tool is simple (one parameter, no output schema), and the description sufficiently explains its purpose and the meaning of parallels. It lacks explicit notes on behavior or edge cases, but given the low complexity, the description is nearly 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 input schema already provides 100% coverage for the single parameter 'uid' with a clear description and example. The description does not add parameter-specific details, but since schema coverage is high, 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 clearly states the tool's function: retrieving a list of parallels for a sutta, and further explains what parallels are (equivalent texts in other traditions). This specific verb+resource combination distinguishes it from siblings like get_sutta or get_sutta_meta.

  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 this tool (when you need parallel texts for a sutta), but it does not explicitly mention alternatives or exclusions. It would be stronger if it contrasted with get_sutta for the original text or get_sutta_meta for metadata.

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

• get_sutta_metaA
  3.8/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 return fields (metadata contents), which is some behavioral disclosure, but it does not explicitly mention read-only nature, error behavior, or limitations. The verb 'get' implies non-mutating but lacks explicit detail.

  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 concise sentence with a colon and comma-separated list of fields, front-loaded with the verb. No filler, 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 only 2 simple parameters, no output schema, and no annotations, the description adequately lists the primary return fields. However, it omits details like field formats, default language behavior, or how this relates to sibling tools, leaving minor 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 coverage is 100%: both parameters have descriptions (uid example, language for blurb/title). The description does not add semantic value beyond what the schema already provides, so the baseline score 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 'Lấy' (get) with a resource 'metadata của một sutta' and enumerates the exact metadata fields returned (name, blurb, difficulty, parallels count, translations, link). This clearly distinguishes it from sibling tools like get_sutta (full text) and get_parallels (parallels only).

  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 (when metadata is needed) but provides no explicit alternatives or conditions like 'use get_sutta for full text'. Guidance is intuitive from the name and list, but not directly stated.

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

• list_divisionsA
  3.8/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 transparency burden. It does disclose a key behavioral trait: 'Dữ liệu hardcode, không gọi API' (hardcoded data, no API call), indicating static results and no network dependency. It also mentions the optional filter. However, it does not describe the output format, error handling, or any limitations beyond the hardcoded nature, leaving some gaps.

  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 exactly two sentences, front-loaded with the main action and a useful behavioral note. It contains no redundant phrases, filler, or unnecessary details, making it highly concise and well-structured.

  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 list tool with one optional enum parameter, no output schema, and good schema coverage, the description covers the core aspects: purpose, filtering, and data source. It does not explicitly describe the return format, but the tool's name and purpose strongly suggest a list of division names. This is adequate for the tool's low complexity, though a brief note on the response shape would make it 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 input schema already provides 100% coverage of the sole parameter 'pitaka', including enum values and the default behavior when omitted ('Bỏ trống → trả về tất cả'). The description's mention of filtering by pitaka adds little beyond the schema. The high schema coverage sets a baseline of 3, and no significant additional meaning is added by the description.

  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 starts with 'Liệt kê các divisions' (list the divisions), using a specific verb and resource. It specifies the domain 'trên SuttaCentral' (on SuttaCentral), which distinguishes it from other listing tools. Though it doesn't explicitly contrast with siblings, the purpose is unambiguous and accurate.

  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: use this tool to list divisions, optionally filtered by pitaka. It does not explicitly mention when not to use it or compare with siblings like search_topic or get_sutta. There are no exclusions or alternative recommendations, so guidance is implied but not fully developed.

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