Server Quality Checklist

Tool Scores

• get_database_clusterC
  2/5.0
  Behavior2/5

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

  The description implies a read operation, but with no annotations, it fails to confirm idempotency, safety, or any side effects. No mention of output structure or rate limits.

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

  Conciseness2/5

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

  Extremely short, but lacks critical information. Concise at the expense of completeness. The single sentence does not earn its place given missing details.

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

  Completeness1/5

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

  Given the presence of sibling tools, two required params, and no annotations or output schema, this description is insufficient for reliable selection and invocation. It provides almost no context beyond the resource name.

  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?

  With 0% schema description coverage, the description must compensate, but it provides zero information about the required parameters (namespace, name) or their meanings. The agent gains no insight beyond the parameter names.

  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 clearly states it retrieves details of a specific database cluster, but does not differentiate from sibling tools like get_database_cluster_components or get_database_cluster_credentials. The verb 'Get details' is somewhat generic.

  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 on when to use this tool versus alternatives (e.g., get_database_cluster_components). No exclusions or prerequisites mentioned.

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

• get_database_cluster_componentsC
  2.4/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 convey behavioral traits. It does not mention whether the operation is read-only, what happens if the cluster does not exist, or any side effects. The description lacks essential behavioral context for an AI agent.

  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 extremely brief (one sentence), which is concise but borderline under-specified. It front-loads the core action and resource, but the brevity leaves out critical details, making it mediocre rather than optimal.

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

  Completeness1/5

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

  Given no output schema, no annotations, and 0% parameter coverage, the description is severely incomplete. It does not explain what the components are, how they are structured, or any constraints like required permissions, making it inadequate for correct tool 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 the purpose or expected values of the 'name' and 'namespace' parameters. It adds no meaning beyond the schema, failing to help the agent understand what values to provide.

  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 action 'Get components' and the resource 'database cluster'. However, it does not explicitly distinguish from sibling tool 'get_database_cluster', which likely retrieves the cluster itself. The specificity is good but could be enhanced by contrasting with similar tools.

  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 on when to use this tool versus alternatives like 'get_database_cluster' or 'list_database_clusters'. The description provides no context for appropriate usage scenarios or prerequisites.

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

• get_database_cluster_credentialsC
  2.4/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 fully disclose behavior. It states 'Get', implying a read-only operation, but does not mention potential side effects, required permissions, or sensitivity of credentials. This is insufficient for an agent to understand behavioral traits.

  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 very short at one sentence, which is concise but at the cost of completeness. It is front-loaded with the core action, but lacks necessary details, making it minimally acceptable.

  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 lack of annotations, output schema, and parameter descriptions, the description is insufficient for an agent to use the tool correctly. It does not explain what the returned credentials look like, how to interpret the parameters, or any contextual constraints.

  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?

  The input schema has two parameters ('name' and 'namespace') with 0% description coverage, meaning the schema provides no descriptions. The tool description only mentions 'a specific database cluster' without explaining how these parameters identify the cluster or what values are expected. No additional meaning is added beyond the parameter titles.

  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 uses the verb 'Get' and specifies the resource 'credentials for a specific database cluster', making the tool's purpose clear. However, it does not differentiate from sibling tools like 'get_database_cluster', which might retrieve cluster metadata, and fails to clarify what exactly 'credentials' entails (e.g., connection string, username/password).

  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 usage guidelines are provided. The description does not indicate when to use this tool versus alternatives like 'get_database_cluster' or 'list_database_clusters', nor does it specify prerequisites or typical use cases.

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

• list_database_clustersB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, and the description only says 'List available database clusters' which indicates a read operation. It fails to disclose potential behavioral traits such as pagination, authorization requirements, or rate limits.

  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 a single sentence, concise and front-loaded. It is efficient but could be more informative without increasing length significantly.

  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?

  For a simple list tool with one parameter and no output schema, the description is minimal. It does not mention pagination, filtering, or the structure of the returned data, leaving gaps for an AI agent.

  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 'namespace' with 0% description coverage. The description only mentions 'in the specified namespace' but adds no additional meaning about the parameter's purpose, format, or allowed values.

  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 'List' and the resource 'available database clusters' with a scope 'in the specified namespace'. It distinguishes itself from sibling tools like create, get, get components, and get credentials.

  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 for listing clusters but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it.

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

• create_database_clusterA
  3.6/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 burden. It confirms mutation ('create') but does not disclose potential side effects, auth requirements, idempotency, failure behavior, or any constraints beyond parameter descriptions.

  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 front-loaded with the main purpose, followed by a clear list of parameter descriptions. It is appropriately sized for a tool with 9 parameters, but could be slightly more concise by grouping optional defaults.

  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 complexity (9 parameters, no output schema), the description covers parameter meanings fully but lacks details about the return value, asynchronous behavior, or validation rules. It is minimally adequate for a creation tool.

  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?

  With schema description coverage at 0%, the description compensates by providing meaningful explanations for each parameter, e.g., 'storage_size: Size of storage using the Mi, Gi suffix' and 'cpu: CPU cores per replica'. This adds significant value beyond the schema's type and default.

  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 starts with 'Create a new database cluster in the specified namespace,' clearly stating the verb (create) and resource (database cluster). It distinguishes from sibling tools like get_database_cluster and list_database_clusters, which are read-only.

  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 this is for creation, but provides no explicit guidance on when to use this tool versus alternatives, such as when to use editing tools. It lacks when-not-to-use or prerequisite conditions.

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