Server Quality Checklist

Tool Scores

• doh_statusC
  2/5.0
  Behavior1/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 of behavioral disclosure. It does not state whether the operation is read-only, what side effects may occur, what the response format is, or any error conditions. For a status tool this is a critical omission.

  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 short sentence with no fluff, but it is under-specified. It is not effectively front-loaded because it fails to convey the tool's purpose clearly enough; brevity is achieved but at the cost of clarity.

  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 simplicity (no params, no output schema), the description still needs to convey the tool's function and how it differs from check_health. It does not mention return values, read-only behavior, or the relationship to sibling tools, so an agent lacks critical information to use it correctly.

  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 zero parameters, so the baseline is 4. The description does add context about the domain (DoH local bridge via dnsproxy/launchd) which helps an agent understand the subject, even though it does not explain any parameter (as there are none).

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

  Purpose2/5

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

  The description 'Status bridge DoH lokal (dnsproxy via launchd).' is a label-like phrase rather than a clear action. It names a resource (bridge DoH) and context (dnsproxy/launchd) but lacks an explicit verb like 'retrieve' or 'check', and does not distinguish it from the sibling check_health which likely serves a similar status purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus any of its siblings. No context is provided about the intended scenario or alternative tools, leaving an agent without any basis to select this tool over check_health.

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

• remove_domainB
  3.3/5.0
  Behavior3/5

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

  With no annotations, the description must disclose behavior on its own. It states that the tool modifies a registry and a Caddy site and triggers a reload, which are relevant side effects. However, it does not mention irreversibility, permission requirements, or failure modes, so it's partially transparent.

  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 with the core action front-loaded. There is zero wasted text, and every word contributes to the meaning.

  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?

  For a simple one-parameter removal tool, the description covers the essential steps (remove, reload) but leaves out important context like whether the domain must exist, what happens on failure, or any safety caveats. Given the lack of an output schema and annotations, it is minimally complete but not thorough.

  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 0%, so the description must explain the 'name' parameter. The phrase 'Hapus nama.test' implies that 'name' is the domain to remove, which gives basic meaning. However, it lacks format, examples, or edge-case details, so it only partially compensates for the gap.

  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 (remove) and the resource (domain from registry and Caddy site) with a reload step. It is concise and unambiguous, though it does not explicitly contrast with sibling tools like add_domain, so it's not a full 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. There is no mention of conditions, prerequisites, or when not to use it. The name implies removal but that's not explicit enough for an agent to make a confident choice.

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

• check_healthA
  3.5/5.0
  Behavior2/5

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

  With no annotations, the description bears full responsibility for disclosing behavior. It lists the components checked but does not state that the operation is read-only, whether it makes any changes, or what the output/return format is. An agent cannot infer side effects, permission requirements, or how to interpret results from this description alone.

  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 with no filler. It front-loads the action and resource, then lists the components. Every word earns its place, and the structure is immediately scannable.

  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 (no parameters, no output schema), the description covers the scope of what is checked. However, it does not explain what the result looks like (e.g., a summary, pass/fail, detailed diagnostics) or what 'health' means in practice. Since the output schema is absent, the description should provide at least a hint of return semantics, which it omits.

  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 no parameters, so the schema is trivially complete. The description inherently needs no parameter explanations. Per the rubric, a zero-parameter tool gets a baseline of 4, and there is no reason to deduct since the description adds no misleading or missing parameter info.

  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 uses a specific verb ('Cek kesehatan' = check health) and a specific resource ('rantai devns' = devns chain), and enumerates the components checked (resolver, DNS, Caddy, HTTPS). This clearly distinguishes it from siblings that manage domains (list_domains, add_domain, remove_domain) or check DoH status (doh_status). It is not a tautology and provides concrete scope.

  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 states what it does (checks health) but gives no guidance on when to use it versus alternatives. It does not mention whether to prefer this over doh_status for DoH-specific checks, nor does it specify prerequisites or typical scenarios. The context is implied ('health') but there is no explicit when/when-not or alternative naming.

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

• list_domainsA
  3.8/5.0
  Behavior2/5

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

  No annotations are present, so the description carries the full burden. It describes a read operation (listing) but does not explicitly state that it is read-only, non-destructive, or free of side effects. It also does not mention any error conditions, rate limits, or data volume concerns. For a tool with no annotation coverage, more behavioral disclosure is 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 a single, direct sentence that front-loads the action (list all) and the resource (registered *.test domains) and includes the key output details. Every word earns its place; there is no 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 zero-parameter tool with no output schema, the description adequately specifies what the tool returns: registered domains, ports, and port status. It does not mention pagination, sorting, or limits, but for a simple list operation, this is not a critical omission. The description is sufficient for an agent to call and interpret the result correctly.

  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 zero parameters, so the description does not need to elaborate on them. The schema coverage is trivially 100% and there is nothing missing. The baseline of 4 applies because there are no parameters to describe.

  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 a specific action (list all) on a specific resource (registered *.test domains) and includes the details it returns (port and port status). It is clearly distinct from sibling tools like add_domain, remove_domain, check_health, and doh_status, which serve different purposes.

  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 when-to-use or when-not-to-use guidance is provided. The name and description imply this is the tool for viewing all domains, but it does not mention alternatives like check_health or any conditions that would make another tool more suitable. The usage context is implied but not explicit.

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

• add_domainA
  4.2/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 of behavioral disclosure. It does mention the key side effect (reloads Caddy) and the required domain naming pattern. However, it omits details like idempotency, failure modes, or whether existing entries are overwritten, leaving some behavioral ambiguity.

  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 that front-loads the core action, followed by the naming constraint and an example. There is zero filler, and every part contributes to understanding the tool. It is exceptionally concise and well-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?

  For a simple two-parameter tool with no output schema, the description covers the purpose, the side effect, naming rules, and an example. It is mostly complete, but it does not describe what the return value or success/failure indications look like, which would be helpful for an agent interpreting the result.

  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 descriptions are already clear (name without .test, local port), so baseline is 3. The description adds value by specifying the exact character pattern for name ([a-z0-9-]) and providing a concrete example, which goes beyond the schema. This elevates the score to 4.

  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 a specific action (register a .test domain pointing to 127.0.0.1:port) and explicitly mentions reloading Caddy, making it distinct from sibling tools like list_domains or remove_domain. The verb 'Daftarkan' and resource are clear, and the example reinforces the purpose.

  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 a naming constraint ([a-z0-9-]) and a concrete example, which clarifies when and how to call it. It does not explicitly mention alternatives or exclusion scenarios, but the sibling names make the intended use obvious. The guidance is adequate, though not exhaustive.

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