Server Quality Checklist

Tool Scores

• validate_code_standardsB
  3.3/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 states the tool validates code and returns problem lists with suggestions, but doesn't disclose important behavioral traits like whether this is a read-only operation, what happens with invalid inputs, whether there are rate limits, or what authentication might be required. For a validation tool with zero annotation coverage, this leaves significant 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, efficient sentence that clearly states the tool's purpose and output. Every word earns its place - it specifies what's being validated (code snippets), against what standard (M8 development standards), and what's returned (problem lists and modification suggestions). No wasted words or redundant information.

  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 the tool's moderate complexity (3 parameters, validation logic) and the absence of both annotations and output schema, the description is minimally adequate. It explains what the tool does and what it returns, but doesn't provide enough context about behavioral aspects or error handling. The lack of output schema means the description should ideally say more about the return format, but it only mentions '问题列表和修改建议' (problem lists and modification suggestions) without detail.

  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 description coverage is 100%, so the schema already documents all three parameters (code, file_type, vue_version) with their descriptions and constraints. The description doesn't add any parameter-specific information beyond what's in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in 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 clearly states the specific action ('验证' - validate), the resource ('代码片段' - code snippet), and the purpose ('是否符合 M8 开发规范' - whether it complies with M8 development standards). It distinguishes itself from sibling tools (create_ioc_page, create_page, get_prompt) by focusing on validation rather than creation or retrieval operations.

  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. While it's clear this is for code validation, there's no mention of prerequisites, typical use cases, or when other tools might be more appropriate. The sibling tools are all creation/retrieval tools, so the distinction is obvious, but no explicit usage context is provided.

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

• create_pageB
  3.4/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions the three-step automation process (load specs, generate code, validate), it lacks critical behavioral details: whether this creates files/directories, what permissions are needed, whether it overwrites existing files, error handling, or output format. For a complex 9-parameter creation tool with no annotations, this is insufficient transparency.

  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 efficiently structured in three sentences: recommendation tagline, automation steps, and user guidance. Each sentence adds value - the first establishes priority, the second explains the automated workflow, the third clarifies the user's role. While concise, it could be slightly more front-loaded with the core purpose.

  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 the tool's complexity (9 parameters, creation operation) with no annotations and no output schema, the description is moderately complete. It explains the high-level automation workflow but lacks details about what exactly gets created, where outputs go, error conditions, or success indicators. The 100% schema coverage helps, but for a creation tool, more behavioral context would be beneficial.

  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 description doesn't mention any parameters directly, but with 100% schema description coverage, the schema already documents all 9 parameters thoroughly with descriptions, enums, defaults, and requirements. The description's focus on the overall automation workflow provides some context for why these parameters matter, but adds minimal specific semantic value beyond what the schema provides.

  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's purpose: '一站式 M8 页面生成工具' (one-stop M8 page generation tool) and specifies it '自动完成：1.加载完整规范 2.生成代码 3.验证规范' (automatically completes: 1. loads complete specifications, 2. generates code, 3. validates specifications). It distinguishes from siblings by emphasizing its comprehensive automation approach, though it doesn't explicitly name alternatives.

  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 clear usage context with '【推荐使用】' (recommended use) and '用户只需描述页面需求即可，无需手动调用其他工具' (users only need to describe page requirements, no need to manually call other tools). It implies this tool should be used for comprehensive page generation rather than piecemeal approaches, though it doesn't explicitly state when NOT to use it or name specific alternatives among siblings.

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

• get_promptA
  3.5/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 discloses that the tool retrieves a 'System Prompt' with '核心规范和工具调用指令' (core specifications and tool invocation instructions), implying it's a read-only operation that provides configuration data. However, it doesn't mention behavioral traits like error handling, performance, or any constraints (e.g., rate limits, authentication needs). The description adds basic context but lacks depth for full transparency.

  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 concise and well-structured in two sentences: the first states the purpose, and the second provides usage advice. It's front-loaded with the core function and avoids unnecessary details. However, it could be slightly more efficient by integrating the advice more seamlessly, but overall, it's clear and wastes no words.

  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 the tool's simplicity (0 parameters, no annotations, no output schema), the description is moderately complete. It explains what the tool does and suggests how to use the output, but it lacks details on the return format (e.g., what the 'System Prompt' looks like) or any error conditions. Without an output schema, the description should ideally hint at the response structure, but it only covers basic context, leaving gaps for full agent understanding.

  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?

  The tool has 0 parameters, and schema description coverage is 100% (as there are no parameters to describe). According to the rules, with 0 parameters, the baseline score is 4. The description doesn't need to compensate for any parameter gaps, and it appropriately doesn't discuss parameters, focusing instead on the tool's purpose and usage.

  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's purpose: '获取配置给 AI (Cursor/Windsurf) 的最佳 System Prompt，包含核心规范和工具调用指令' (Get the best System Prompt configured for AI (Cursor/Windsurf), including core specifications and tool invocation instructions). It specifies the verb '获取' (get) and the resource 'System Prompt', making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'create_ioc_page' or 'validate_code_standards', which appear unrelated, so it doesn't fully address sibling distinction.

  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 provides implied usage guidance: '建议将其复制到 .cursorrules 或 .windsurfrules 文件中' (It is recommended to copy it to .cursorrules or .windsurfrules files), suggesting when to use the output. However, it lacks explicit when-to-use vs. when-not-to-use criteria or named alternatives. The guidance is practical but not comprehensive, leaving some ambiguity about optimal usage scenarios.

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

• create_ioc_pageA
  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 full burden and does well: it discloses that the tool automatically executes 'npm run ioc create' in the project root directory (a critical behavioral trait), warns about automatic component creation, and details the directory structure generated. It mentions important checks (e.g., base.js consistency) but doesn't cover error handling or rate limits, keeping it from a perfect score.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is appropriately sized but not optimally structured: it uses emojis and sections (e.g., '重要', '使用前必读'), which aids readability, but includes extensive details like directory listings and configuration types that might be verbose. Some sentences (e.g., configuration design suggestions) could be trimmed for conciseness, though the front-loaded warnings are effective.

  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 complexity (8 parameters, no annotations, no output schema), the description is largely complete: it covers purpose, usage, behavioral traits, and process steps. However, it lacks details on return values or error handling, which are important for a tool that executes commands and generates code. The absence of an output schema means the description should ideally explain what is returned, but it only hints at '返回生成代码' (return generated code).

  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 baseline is 3. The description adds minimal parameter-specific semantics beyond the schema—it emphasizes project_path as '必填' (required) and links component_name to directory naming, but most parameter details (e.g., config_options types, mock_data_structure) are already well-documented in the schema. No significant value is added over the schema's thorough descriptions.

  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: '生成符合 M8 低码平台规范的组件代码' (generate component code compliant with M8 low-code platform specifications). It specifies the verb ('生成' - generate) and resource ('组件代码' - component code), and distinguishes from siblings like create_page (likely for pages) and get_prompt/validate_code_standards (different functions).

  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 usage guidelines: it states when to use ('优先使用 em-组件库' - prioritize using em-component library), when not to use (only custom implementation when no matching component exists), and alternatives (specific em- components for various UI elements like em-swipe for carousels). It also outlines prerequisites like providing project_path and checking base.js.

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