Server Quality Checklist

Tool Scores

• check_permissionC
  2.2/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 of disclosing behavior. It mentions an 'execution point' and a rule for write tools, but does not clarify side effects, authorization requirements, or what happens when permission is denied. The behavior remains largely opaque.

  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 a single sentence and thus concise, but it is densely packed with jargon and lacks any structural separation of concepts. It is not well-organized for quick comprehension, though it does fit in minimal space.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has three parameters, no annotations, and an output schema that is not described, the description is insufficient. The agent is left without understanding when to invoke it, what the return format looks like, or how the permission decision is made, making it incomplete for reliable invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description does not explain any of the three parameters. While 'caller' and 'MCP' are implicit, the 'action' parameter is not mentioned, and no guidance is given for valid values or how parameters interact with the permission matrix.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states it is a permission matrix execution point checking caller x MCP x read/write, which identifies the resource and action. However, it is phrased as a noun phrase rather than a clear verb+resource imperative, and the term 'MX-3 收口判定' is cryptic without context, making the purpose somewhat vague.

  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 hints that write tools are judged by a specific rule ('写工具按 MX-3 收口判定'), but it does not clearly state when to use this tool versus alternatives like check_safety_gate or classify_intent. No explicit conditions, prerequisites, or exclusions are provided.

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

• extract_slotsC
  2.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 carries full responsibility for disclosing behavior. It mentions 'rule-based' but does not describe whether it modifies input, what the output structure is, error handling, or side effects. The presence of an output schema mitigates this somewhat, but the description itself is insufficient.

  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 appropriately short and front-loaded with the core purpose. It is a single, direct sentence without filler, though it could benefit from a brief note on input. It is concise but not minimal to the point of under-specification.

  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?

  This is a simple tool with a single parameter and an output schema, so it does not require extensive description. However, the lack of usage or behavioral context makes it incomplete for an agent encountering it for the first time. Given the sibling tools, some integration guidance would help but is not critical.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It lists slot types (which are likely output fields) but gives no explanation of the 'text' parameter's meaning or format. The description does not help an agent understand what value to pass, only what the tool extracts.

  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 function: rule-based slot extraction, listing specific slot types (patient_id, food, etc.). This is a specific verb+resource that distinguishes it from siblings like check_permission or classify_intent. However, it does not explicitly mention that the input is text, which the schema reveals.

  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?

  No guidance is provided on when to use this tool versus alternatives, or any context for its invocation. The description is purely functional without usage scenarios, prerequisites, or exclusions.

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

• classify_intentA
  3.5/5.0
  Behavior3/5

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

  The description adds behavioral details beyond nothing (no annotations) by noting that rule matches take priority and listing return fields. However, it does not disclose side effects, authorization needs, or failure behavior, leaving the full burden unmet.

  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, information-dense sentence. It front-loads the action and includes the key rule-priority constraint without any filler.

  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 single-parameter classifier, the description covers the core behavior and outputs, especially with the output schema present. Missing usage guidance and edge-case behavior are notable but not critical.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has one parameter 'text' with 0% description coverage, and the description does not mention this parameter or its format. It fails to compensate for the coverage gap, though the parameter name is self-explanatory.

  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 states the tool performs 'intent routing' and specifies the exact outputs: target MCP, allowed caller, slots, and confidence. This clearly distinguishes it from sibling tools like check_permission, extract_slots, and check_safety_gate, which handle different concerns.

  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?

  No explicit guidance is given on when to use this tool versus the siblings. There is no mention of prerequisites, sequencing, or exclusions; the rule-priority note is algorithmic, not usage context.

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

• check_safety_gateA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the transparency burden. It discloses the gate's blocking behavior (allow=false → terminate routing) and lists the three policy domains, offering useful operational context beyond a simple 'check.' It does not detail side effects or permissions, but for a read-only-style safety gate, this is adequate.

  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: the first fronts the primary function with policy specifics, and the second gives the critical operational instruction. Every phrase earns its place with no redundancy or fluff.

  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 tool's gate role and the required action on denial, and an output schema exists to define return values. However, it lacks parameter explanations and explicit usage conditions relative to sibling tools, leaving moderate gaps for a tool with 3 parameters and no annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has three parameters with 0% description coverage, and the tool description does not explain any of them. The 'P0 critical word scan' hints that the 'intent' parameter is likely scanned, but no explicit mapping is provided, leaving the agent to infer parameter meanings.

  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 defines the tool as a safety gate with specific responsibilities: P0 critical word scanning and enforcement of MX-1/MX-2/MX-3 policies. This distinguishes it from siblings like check_permission and classify_intent, and the behavioral consequence (terminate routing on allow=false) further specifies its unique role.

  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 states when this tool must be used by the scheduling agent (before routing) and mandates termination on a negative result, providing clear contextual guidance. However, it does not explicitly contrast with alternatives or state when not to use it, so it falls short of full exclusions.

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