Server Quality Checklist

Tool Scores

• get_departure_citiesA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It mentions fuzzy matching by Chinese/pinyin/English and a limit parameter, but does not describe the output format, behavior on no matches, or whether results are sorted. Basic behavior is disclosed, but some gaps remain, so a 3.

  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 the main purpose front-loaded ('查询携程出发城市ID'), followed by a concise workflow explanation. No redundant words; every phrase adds value.

  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 the tool's simplicity (two parameters, no output schema), the description adequately covers purpose, when to use, and how the result feeds into other tools. It doesn't detail the response structure, but for a lookup tool this is acceptable. Slightly more could be said about the return format, hence a 4.

  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 both parameters (keyword and limit) with full descriptions, including examples. The description adds no new parameter-level detail beyond what the schema already provides, so a baseline 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 queries Ctrip departure city IDs, using the specific verb '查询' and resource '出发城市ID'. It also explains the workflow of looking up the ID before passing it to search_tours or recommend_tours, which distinguishes it from sibling tools.

  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 provides explicit context: 'when user mentions a departure city, call this tool first' (当用户提到某出发城市...先调用本工具). It also explains how the ID is used downstream, but does not explicitly mention exclusions or alternatives like get_filter_options. Clear context, no exclusions, so a 4 is appropriate.

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

• get_filter_optionsA
  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 for behavioral disclosure. It implies a read-only query by using '查询' (query) but does not describe the return format, pagination, or any potential side effects. It mentions returning 'fastFilters' but lacks detail on structure or error 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 two sentences, front-loaded with the core purpose in the first sentence and usage guidance in the second. No fluff, every word serves a purpose.

  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 tool with one parameter and no output schema, the description sufficiently explains the tool's role and usage context. However, it could mention what the output looks like or any prerequisites (e.g., authentication), but given the simplicity, the description is largely 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 keyword parameter with a description (destination/theme keyword with examples). The tool description adds no additional meaning about the parameter, so it does not go beyond the schema. Baseline of 3 is appropriate given high 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 clearly states the tool queries available filters and their optional values ('fastFilters') from the Ctrip integrated list. This is a specific verb-resource combination that distinguishes it from sibling tools like search_tours and recommend_tours, which are for searching tours, and get_departure_cities, which is for departure cities.

  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 says when to use this tool: when mapping user requirements to filter parameters/enums, call this tool first, then pass the obtained values to search_tours or recommend_tours. This provides clear context and a workflow, effectively distinguishing it from alternatives.

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

• search_toursA
  4.5/5.0
  Behavior4/5

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

  描述明确说明返回Markdown表格，且要求最终回复直接使用该表格，不要改写格式，这是有用的行为提示。还提到limit自动分页、travel_way筛选仅当用户明确说私家团等才使用，以及days参数的计算逻辑。无注解，因此描述承载了行为披露责任，较充分。

  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?

  描述紧凑，一段话概述用途和关键参数，无冗余。每句都提供价值：使用场景、自动分页、Markdown表格、筛选能力。

  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?

  19个参数但仅1个必需，schema描述全覆盖。描述给出了关键计算规则和筛选触发条件，输出格式已说明（Markdown表格）。尽管无输出schema，但描述已足够让agent正确调用，整体完整。

  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描述覆盖100%参数，描述在schema基础上添加了关键语义：days参数精确计算规则（返程-出发+1）、travel_way的私家团触发条件、include_traffic与vehicle的互斥指导、departure_date仅出发日。这些额外信息确实超过schema本身，因schema描述已有不少，但描述增加了决策逻辑，所以给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?

  描述明确说明该工具在携程跟团游列表中搜索并返回结构化产品列表，并列出用法（列出/搜索/看看）和可筛选维度（销量、好评等）。它通过与recommend_tours的对比来区分，明确‘直接调用本工具（无需用户指定工具名）’，但与兄弟工具区分不够明确——虽然未明确提及兄弟工具名称，但上下文应足够。

  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?

  明确指明何时使用（列出/搜索/看看携程产品时）以及无需用户指定工具名。虽未明确说何时不使用，但提到‘直接调用’并对筛选、排序、分页有用法指引。缺少对recommend_tours等兄弟工具的明确排除，但已有上下文可推断。

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

• recommend_toursA
  5/5.0
  Behavior5/5

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

  No annotations are provided, so the description bears full responsibility. It thoroughly discloses behavior: it returns a Markdown table, sorts by multiple dimensions, and respects numerous parameter constraints (e.g., '仅当用户明确说' clauses). This high level of detail ensures the agent understands side effects and conditional logic, exceeding typical transparency.

  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, well-organized paragraph that front-loads the purpose and usage, then details the output. Despite the large parameter count, the description is concise and avoids redundancy—every sentence adds necessary context. The format is clean and easy to parse.

  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 complexity of 24 parameters and many conditional rules, the description is remarkably complete. It covers the core behavior, output format, sorting logic, and provides explicit guidance on how to interpret user intents for each parameter. No major aspects are missing, and the lack of an output schema is mitigated by the clear statement that the result is a Markdown table.

  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?

  All 24 parameters have rich, descriptive explanations that go beyond type information. Examples include team_size mapping from user counts, departure_date format and conditionality, and explicit instructions like 'min_socre' only when the user requests rating priority. This exceeds the 100% schema coverage baseline by providing actionable context for each parameter.

  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 purpose: to search and recommend tour products on Ctrip based on user requirements, with sorting and TopN output. It explicitly lists the action verbs (找/推荐/搜索/比较) and specifies the product types covered, making its function unambiguous and distinct from sibling tools like search_tours.

  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 provides explicit when-to-use guidance: it says to call this tool directly whenever the user asks to find, recommend, search, or compare these tour products, without needing the user to name the tool. It also explains sorting dimensions and output format, covering the primary usage scenarios.

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