Server Quality Checklist

Tool Scores

• mcp_cook_getAllRecipesB
  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 alone must convey behavioral details. It only states the action and does not disclose return format, pagination, ordering, or potential large response size. This leaves the tool's behavior underspecified.

  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 with no filler. It is appropriately concise for a simple tool, achieving maximum efficiency.

  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 tool is simple, but with no output schema and no annotations, the description should clarify what is returned (e.g., an array of recipes). It does not, leaving the return value implicit. The minimal description is adequate for a basic list action but lacks completeness.

  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 has one parameter 'no_param' described as '无参数' (no parameter), covering 100% of the schema. The description adds no parameter information, but with full schema coverage, the baseline of 3 is appropriate.

  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 '获取所有菜谱' (Get all recipes) clearly states the tool's action and resource, and the 'all' scope distinguishes it from siblings like getRecipesByCategory and getRecipeById. However, it does not explicitly contrast with alternatives, so it is not a perfect 5.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention that it is suitable for retrieving every recipe without filters, nor does it point to siblings for filtered or single-recipe needs.

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

• mcp_cook_getRecipesByCategoryA
  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 of behavioral transparency. It accurately describes a read-only query ('查询') and enumerates valid categories, but does not disclose any additional behavior such as return format, pagination, or safety guarantees. It is not misleading, but it is minimal.

  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, front-loaded with the action, and lists the categories compactly. Every word earns its place with no redundancy or noise.

  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 one-parameter tool with 100% schema coverage, the description provides enough context to form a valid request, including all allowed values. It lacks explicit return-format information, but the simple nature of the query tool makes this acceptable. Sibling tools are not referenced, slightly reducing completeness.

  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% with a description and enum for the single 'category' parameter. The description repeats the enum values exactly, adding no semantic information beyond what the schema already provides. 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 action (query) and resource (recipes) with a specific scope (category). It also enumerates all 10 valid categories, which distinguishes this tool from siblings like getRecipeById (by ID) and getAllRecipes (no filter).

  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 lists valid categories but does not explicitly state when to use this tool versus alternatives such as getAllRecipes or recommendMeals. Usage is implied by the category filter, but no exclusions or alternative guidance is provided.

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

• mcp_cook_whatToEatA
  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 discloses that the tool performs a recommendation based on people count and returns dish combinations, but it does not mention side effects, limitations, or output structure. This is adequate but not detailed.

  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, direct sentence that wastes no words and leads with the user need. It is perfectly sized for the simplicity of the tool.

  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 tool with one well-documented parameter and no annotations or output schema, the description covers the core purpose and expected output at a high level. It could specify the return structure or mention that it only uses peopleCount, but overall it is reasonably 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 fully describes the 'peopleCount' parameter, including range and behavioral effect, so the description adds no additional parameter-level meaning. Baseline 3 applies due to high 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 clearly states the tool recommends suitable dish combinations based on the number of diners, which is a specific verb+resource+condition. However, it does not explicitly differentiate itself from the sibling tool 'recommendMeals', so it falls short of a 5.

  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 opening question '不知道吃什么？' and the condition '根据人数' provide a clear context for when to use this tool. It does not mention exclusions or alternative sibling tools, but the use case is well implied.

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

• mcp_cook_recommendMealsA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the main behaviors (recommend, create plan, create shopping list) but does not mention limitations such as what happens if no recipes match, whether it filters by category, or the exact output structure. This is adequate but has 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 a single, compact sentence that front-loads the main action and includes the key outputs. No unnecessary words or repetition.

  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?

  Given no output schema and no annotations, the description should explain what the agent can expect. It mentions creating a weekly plan and a rough shopping list, but lacks detail on the return format, failure modes, or exact recipe selection logic. This is a moderate gap for a complex tool.

  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 schema already documents all three parameters. The description restates the concepts (忌口, 过敏原, 人数) but adds no new semantic detail about how they influence the result. 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's function with specific verbs: it recommends recipes based on user constraints (忌口, 过敏原, 人数) and creates a weekly meal plan with a rough shopping list. This distinguishes it from sibling tools that simply retrieve recipes by ID or category.

  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 implies a clear use case: when the user has dietary restrictions/allergies and needs a weekly plan. It does not explicitly contrast with sibling tools or state when not to use, but the context is clear enough for an agent to select it appropriately.

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

• mcp_cook_getRecipeByIdA
  4/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 of behavioral disclosure. It discloses that the operation is a query (read) and that the response includes ingredients and steps, which gives some sense of the return content. However, it does not mention potential multi-result behavior from fuzzy name matching, error conditions, or lack of explicit read-only confirmation. While not misleading, it adds only modest context beyond the basic action.

  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, concise sentence that front-loads the essential purpose (query by name/ID for complete details) and specifies the returned content. Every word contributes value, and there is no redundancy or extraneous information.

  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 (one parameter, no nested objects, no output schema), the description adequately conveys the operation and the nature of the returned information ('完整详情' plus ingredients and steps). It does not describe edge cases like multiple matches or not-found behavior, which would be valuable for full completeness, but for a straightforward lookup tool, this level of detail is largely sufficient. A slightly richer statement about possible multiple results from fuzzy matching would have earned a 5.

  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 describes the 'query' parameter as accepting a recipe name or ID with fuzzy name matching, which provides 100% coverage. The description merely repeats this information ('根据菜谱名称或ID') without adding new meaning, syntax details, or usage nuances. Therefore, baseline score 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 action (查询/query) on a specific resource (specified recipe by name or ID) and enumerates the content of the returned details (食材、步骤等). This distinguishes it from sibling tools like getAllRecipes or getRecipesByCategory, which are list or category-based, not detail lookups.

  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 phrasing '根据菜谱名称或ID查询指定菜谱的完整详情' clearly indicates this tool is intended for retrieving a single recipe's complete details by name or ID, which is a distinct use case from listing all recipes or browsing by category. Although it does not explicitly name alternatives, the context of a targeted lookup is evident and no exclusions are implied. This meets the 'clear context, no exclusions' criterion, but stops short of explicitly naming sibling alternatives.

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