Server Quality Checklist

Tool Scores

• review_codeA
  3.5/5.0
  Behavior2/5

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

  Without annotations, the description carries full burden. It does not disclose side effects, authentication needs, rate limits, or whether the tool is read-only. Only basic functionality is described.

  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, with a clear purpose statement followed by a parameter list. It is front-loaded and contains no redundant text, though it could be slightly more 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?

  Given the output schema exists, the description does not need to explain return values. It adequately covers tool purpose and parameters. The sibling context helps frame usage, making it complete enough.

  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 50%, and the description adds meaning for required parameters (CODE as code text, cd as working directory) and lists optional ones with brief context. However, no detailed constraints or formats are provided beyond 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 performs code review and lists specific output categories (risks, bugs, readability, security, suggestions). It distinguishes from siblings like 'chat' and 'review_plan' by focusing on code review.

  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?

  No explicit guidance on when to use vs. alternatives. The description implies use for code review but does not provide when-not conditions or mention sibling tools.

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

• review_planA
  3.8/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. It only states the purpose (review) without disclosing behavioral traits like whether it is destructive, read-only, or requires authorization. It adds no behavioral 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 two sentences: one for purpose and one listing parameters. It is concise, front-loaded with the core function, and contains no fluff.

  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 has 6 parameters, 2 required, and an output schema exists. The description gives purpose and parameter list, but lacks information about what the output contains (though output schema handles that) and error conditions. It is mostly complete for a plan review tool, given the supportive schema.

  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 50%. The description lists parameters but adds minimal meaning beyond the schema. For example, it rephrases 'PLAN' as 'plan text' and 'cd' as 'work directory', which matches the schema. It does not add details for parameters like 'model' or 'SESSION_ID' beyond the schema descriptions. This is adequate but not exceptional.

  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 reviews project plans/implementation plans, evaluating requirements, tech choices, risks, and executability. The verb 'review' and resource 'plan' are specific, and it distinguishes from sibling 'review_code' which is for code review.

  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 lists required and optional parameters, implying usage context. It doesn't explicitly state when to use or not use this tool versus alternatives, but the sibling tools provide contrast. Usage is clear for reviewing plans but lacks explicit exclusions.

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

• get_token_statsA
  3.9/5.0
  Behavior3/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. It discloses that SESSION_ID can be empty to return global totals, which is a behavioral trait. However, it does not explicitly state that the operation is read-only or safe, nor does it mention any side effects or permissions needed.

  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 extremely concise with two sentences: the first declares the purpose, the second lists parameters. No extraneous information — every word contributes valuable context for tool selection and invocation.

  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 (2 parameters, output schema exists), the description adequately covers purpose and parameter semantics. It aligns with the sibling context (chat, review tools) and provides enough detail for an AI agent to understand when and how to use it.

  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 description coverage is 50% (only SESSION_ID has a description). The description adds meaning to both parameters: 'cd' is explained as '工作目录' (working directory), and for SESSION_ID, it adds that empty string or omission returns global total across sessions. This compensates well for the missing schema 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: '查询 Coding Bridge MCP 的 token 用量统计' (query token usage statistics). It uses a specific verb and resource, which distinguishes it from sibling tools like chat, review_code, and review_plan.

  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 vs alternatives. It only lists required and optional parameters without any context about appropriate use cases or scenarios to avoid.

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

• chatA
  4/5.0
  Behavior3/5

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

  No annotations are given, so the description carries the full burden. It describes the tool as a 'general multi-turn dialogue,' which implies safe, conversational behavior. However, it does not explicitly disclose that it is non-destructive, has no side effects, or any rate limits. The description is adequate but could be more explicit.

  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 very concise: two sentences plus a brief list of parameters. It front-loads the purpose and then efficiently covers parameters without 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?

  Given the tool's simplicity (chat) and the presence of an output schema, the description covers key aspects: purpose, required/optional parameters, and session continuity. It does not detail return values (not needed due to output schema) and is mostly complete.

  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 schema description coverage is 60%, and the description adds meaning by labeling PROMPT as 'task instruction' and cd as 'working directory,' and explaining optional parameters (SESSION_ID for continuing session, model for version, return_all_messages for full history). This enriches understanding beyond 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 is for 'general multi-turn dialogue' with the Coding Plan service and lists specific use cases (code review, plan review, problem analysis). It distinguishes from sibling tools like review_code and review_plan by emphasizing it is a general-purpose chat.

  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 scenarios ('可用于代码审查、计划审查、问题分析等') but does not explicitly state when to prefer this tool over the specialized siblings. No direct 'when not to use' 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.